GNOME Bugzilla – Bug 734300
[IMAPx] Process untagged EXPUNGE response only once
Last modified: 2015-05-20 15:25:31 UTC
So let's say you have these messages in your inbox: - A - B - C - D - E - F If you select B & C and then move them to some other folder, Evolution will "double" the amount of message disappearing from view... so instead of ending up with "A,D,E,F" in the inbox, you end up with "A,F". If you switch to another folder and come back to the inbox, then "D,E" come back (they were never actually moved along with "B,C"). So then you see "A,D,E,F" as you should. Note that this bug cannot be reproduced by moving back and forth existing messages, it only occurs the first time you move the messages out from the inbox folder. Very weird.
Also, this is with 3.12.4; I don't recall seeing that with previous versions (not 100% sure about the 3.12 series, but certainly not in releases like 3.10.x)
FWIW, this also occurs if you delete and expunge (delete, ctrl+E) when the IMAP account settings are set to use a particular folder as a "real" trash folder.
Still occurs with Evolution 3.12.4 + EDS 3.12.5. Since it "appears" as if more than one message is moved, but the "extra disappearing ones" are not actually moved out, and there is no "corruption" in which targets get moved (ie: evolution doesn't "select the wrong message for the move operation"), I'm guessing it's an Evolution UI bug rather than in EDS?
On the other hand, it seems to be confined to IMAPx, I don't think I've seen this with local/POP messages... maybe Milan would have some clarity on this.
Thanks for a bug report. I cannot reproduce what you described above, but I see other weirdness when using real trash folder. a) I have a copy of my ~/.cache/evolution/mail/<imap-uid>/folders.db file, which I copy back to the original file, thus the account looks like the messages were just received b) run evolution, which shows new 8 messages in Inbox for that account (my Inbox folder has the preview panel off) c) I select by Ctrl+click the second and the third message in the Inbox d) then I drag&drop these two messages to a subfolder of Inbox - currently the Inbox shows 6 new messages and the chosen folder two new messages (there was no new message before I moved there the two) e) select the Inbox's subfolder, there the two new messages and drag&drop them back to the Inbox f) select the Inbox and see 8 new messages, just as they should look like g) select the Inbox's subfolder, it has no new messages, but the subfolder suddenly (after the imapx updates the content by the server data) shows the two moved messages as unread (they should be deleted and moved to the real trash instead) h) repeating f) and g) (just selecting the folders) exhibits the issue again and again. This all suggests that the received changes are not properly saved to local folder summary and that the move to a real trash folder failed for some reason. I was able to see more issues, especially when I changed a folder before the move operation was over, but that's even harder to reproduce than the above steps. I was testing this with git ...3-12 branches of evolution-data-server and evolution git checkouts, eds at 6f6ebad and evo at de69ab3. Thus yes, I can confirm that there are happening weird things in the background when moving messages between folders with real trash folder being set for the account, though I cannot reproduce the issue described in comment #0.
I made some changes for properly storing \Deleted flag, it was done with commits mentioned below. Please try with it, whether it'll help for you too. As I was not able to reproduce your initial issue, I rather saw something opposite, then it's possible this will not help you at all. Created commit 6ffbb16 in eds master (3.13.6+) [1] Created commit a5d3520 in eds evolution-data-server-3-12 (3.12.6+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=6ffbb16
Damn, without patching anything (I'd need someone to provide test RPM packages for F20 for that!), I'm trying to reproduce systematically the issue I reported above and I'm currently unable to trigger it. Have yet to figure out the logic behind this. But I'm pretty sure it still occurs to me on multiple times per day.
I have been seeing the same with evolution as in debian sid, for what it's worth (3.12.6). Other messages disappear temporarily after moving some other message to a different folder (until switching to another folder and then back again to the original folder), all on the same IMAP server. But also I get a "pop-up" above the message list telling me how the mail with message ID x doesn't exist on the server. This happens constantly, so very easy to reproduce for me. My workflow is that new mail ends up in my inbox and I will move messages manually into folders when I'm done with them. I also have enabled the option to show deleted messages in the message list view, in case that makes a difference.
Hmm, it looks like a broken folder summary then, because removed messages should be dropped on the initial folder update automatically. The summary is stored at ~/.cache/evolution/mail/<imap-account-uid>/folder.db file. Moving it away with evolution being off will recreate it the next evolution's start (and the account's update). The side effect is that evolution will download all the folder summaries, the information shown in the message list, which may take a long time with a large mail account.
I can confirm this using 3.16.1, imapx, gmail. Threaded and unthreaded lists. I don't get this with 3.16.1, impax, dovecot.
I don't get this if the mail I'm moving is the first mail listed. If I move "A" in the original report, I keep "B C D E F".
I am able to reproduce this with 3.16.1, GMail account, real Trash set, but not with git master. This is surely an IMAPx bug, I saw the moved message to be claimed as removed, but then sync for changes in that folder finished and it claimed about a removal of the non-removed message.
I don't have a real trash set, and I see this bug.
(In reply to Berend De Schouwer from comment #11) > I don't get this if the mail I'm moving is the first mail listed. If I move > "A" in the original report, I keep "B C D E F". I have now seen the bug under these conditions too.
Fedora 22 now ships with 3.16.2 which seems to help me. Fedora ships two patches, so a stock 3.16.2 might not help. The patches: - fix a 64bit autoconf problem (is this still necessary?) - imapx idle folder vanish which adds a QUEUE_LOCK around imapx_maybe_select() which is a very recent change in git. I only noticed because I wanted to build 3.17.1 on my system to see if that fixed the problem (no git access at work), and I always install fedora-current.rpm from source to make sure builddep is ok. the patch refers #719476
I am finally able to reproduce this with git master too, even without the real trash folder. The trick is to have configured multiple concurrent connections. The thing about the message move is that the server responses with an untagged EXPUNGE response, which references expunged message by its index in the folder, not by its UID. The Google server returns this untagged response on multiple connections, not only on the one which initiated the MOVE command, thus it's processed as many times as the count of the active concurrent connects is (there might be also a constraint to have the other connection active, doing something, in the time of the MOVE command in the other connection, but I didn't investigate this detail that deeply, because it wasn't necessary).
Created commit f813460 in eds master (3.17.2+) Created commit 2eca81a in eds gnome-3-16 (3.16.3+)