Some users were report seeing get_uid_term high in the profiles; so
optimize this:
- make mu_util_get_hash a static inline function (used by get_uid_term)
- don't use 'realpath' in get_uid_term, seem that's the main culprit
- some slight faster string handling there too.
It seems some tools try to interpret the filename of message files,
even though they shouldn't:
"Do not try to extract information from unique names."
In particular, they seem to interpret the first part of the name (before
the first dot) as the # of seconds since the Unix epoch (ie.,
time(NULL)). That's not what mu/mu4e put there.
So, let's conform a bit more to the expected filename (as per the
maildir spec), so we're not confusing those tools.
The core dump only seems to occur if mu4e-headers-include-related is
set to t.
Apparently, std::string's c_str() method is confusing to many
people, c.f.
http://stackoverflow.com/questions/22330250/how-to-return-a-stdstring-c-str
The answer seems to be that the pointer c_str() returns may not be
valid past the current statement; returning it, or even using it
subsequently can have you sending a wild pointer into e.g. g_strdup().
In short, it seems idioms like this are okay:
return g_strcmp0 (s1.c_str(), s2.c_str()) < 0;
Whereas idioms like this are not:
const char *msgid (iter->msgid().c_str());
return msgid ? g_strdup (msgid) : NULL;
At least in my environment by the time we get to g_strdup() the
pointer returned by c_str() is wild and points at garbage. Since
g_strdup() returns NULL if passed NULL, it seems collapsing it into a
single line is not only possible but necessary.
I've looked at all of the calls to c_str() in mu and it appears to
me this was the one remaining one that was bad.
The test fails in some cases with interesting directory setups, although
the function does work. So de-activate the test for now, until we come
up with a better one.
Since `parent` is not really used as a parent, I use it as the last
visited encrypted part while going down the parts-tree.
At the decryption of a part (`mu_msg_crypto_decrypt_part`) I check,
through the GMimeDecryptResult, for signatures (`check_decrypt_result`)
and add them to the part (`tag_with_sig_status`). Any nested parts hold
that encrypted part as their parent. Finally at `handle_part`, for each
part I check if it a descendent of an encrypted part. If so, I proceed
checking for signatures and adding them to the `msgpart`.
This reverts commit 6e9b9ad2d0.
Unfortunately the reverted commit breaks the Signature field for
encrypted and, at the same time, signed messages.
TODO: details button in the Signatures field does not work for such
cases because the signature is encrypted.
Conflicts:
lib/mu-msg-part.c
Add a decryption field of the form
Decryption: 2 part(s) decrypted 1 part(s) failed
Meaning that 2 encrypted mime parts where successfully decrypted and 1
part failed. Note that the number 2 refers to the number of
successfully decrypted mime parts and not the number of successfully
decrypted encryptes multiparts, i.e., if an encrypted multipart
contains 4 parts and decryption is successful the field will be
Decryption: 4 part(s) decrypted
TODO: Add details button listing the names and indexes of the
decrypted (or not) mime-parts
Pull request #483 does not handle encrypted multiparts properly. It
used to just verify the signature and not process the parts of the
multipart. This commit resolves this issue.
Additionally it did not index attachments properly and in the case of a
multipart directly containing more than one multiparts resulted on non
unique indexing of attachments/parts. This commit resolves this issue
as well.
This patch fixes the attachment extraction (open, save, temp) when using
`mu4e`. `mu4e` used to not notify the mu-server about the
mu4e-decryption-policy. As a result mu-server did not decrypt the
attachments for extract, open, or temp.
After a multipart/encrypted part gets decrypted the result is usually a
`multipart/mixed` part (see enigmail).
Before this commit mime multiparts where handled only by
`g_mime_message_foreach`. As a result the decrypted mime multiparts
where not processed.
This patch handles mime multiparts explicitly by removing the
`g_mime_message_foreach` invocations. This might come at the cost of
reduced maintainability, in the case of radical gmime changes. However,
gmime is pretty stable and that scenario is highly unlikely.
TODO: After decryption make any attachments available
When the root set contains only one empty container with one child
first promote the child container to the root set and only then
remove the empty parent container so that the root set never goes
empty.
Also make mu_container_splice_children() do only one thing, that is
promote one container's children to be another container's siblings.
The resultant childless container is no longer removed by this
function.
Fixes#460.
This test reproduces a regression introduced by commit 97101f1f82
("mu: Prune empty container when an only child gets promoted to the
root set").
When the results of a mu-find query contain only a one thread:
$ mu find --threads --fields 'd s' ''
Sat 09 Aug 2014 07:00:00 PM CEST [mu4e] Test Message
`-> Sat 09 Aug 2014 08:30:00 PM CEST Re: [mu4e] Test Message
... and we narrow down the query in such a way that the root message
gets excluded, then a crash occurs:
$ mu find --threads --fields 'd s' '' date:2014-08-09/20:00..2014-08-09/21:00
**
ERROR:mu-container.c:117:mu_container_append_siblings: assertion failed: (c)
Aborted (core dumped)
Reported-by: Josiah Schwab <jschwab@gmail.com>
Traverse the container tree depth first and for each container find
the node in the subtree rooted at this container which comes first in
the descending sort order. Remember it as the subtree leader. Then,
while sorting siblings, compare their subtree leaders instead of the
sibling containers themselves.
IOW, make threads containing the newest message float to the top when
sorting by date in the descending order.
There is no significant performance degradation when sorting a
mailbox with ~16k messages:
$ mu find maildir:/INBOX | wc -l
16503
Current state:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1231.761588 task-clock (msec) # 0.996 CPUs utilized ( +- 1.02% )
1.236209133 seconds time elapsed ( +- 1.08% )
With patch applied:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1459.883316 task-clock (msec) # 0.998 CPUs utilized ( +- 0.72% )
1.462540088 seconds time elapsed ( +- 0.77% )
This implements https://github.com/djcb/mu/issues/164.
