GNOME Bugzilla – Bug 655167
messages moved from IMAP Inbox reappear
Last modified: 2011-12-01 13:10:01 UTC
my apologies if this was already filed, but i could not find a related bug. running Evolution 2.32.2 on Gentoo x86_64 and having a problem where almost all messages moved from the Inbox, whether by a filter, a delete message command, or by actually moving (usually via drag-n-drop), will reappear in the Inbox after a short time (~minute). the moved/deleted original still exists in the new position, thus a duplicate now exists in the Inbox. re-moving/re-deleting the duplicate to the same destination as the original results in obviously 2 messages existing. and sometimes, the original message will appear a 3rd time. at first i thought that this was an IMAP server issue, but it happens with both of my email accounts, which use separate servers, though both IMAP. also, using a IMP webmail interface to my IMAP accounts works without creating duplicates. finally, testing another email client (Claws) also did not exhibit the duplicate message problem, so it seems to be something going on with Evolution. NOTE: i am using a custom trash and spam folder instead of the default "virtual folders". not sure if this changed the "IMAP backend" (which i have read about but have no idea how to change/select) and has caused the issue. thanks.
Thanks for a bug report. That real trash might be causing a trouble here, I suppose it failed to mark moved messages as deleted and move them into the real folder trash, then expunge the folder with moved message to the real trash, for some reason. Could you run evolution in a debug mode and repeat the steps, to see what failed there, please? You can do that from a console with a command like this: $ CAMEL_DEBUG=all evolution &>log.txt Note that this generates quite large debug output, thus I suggest to run evolution, let it settle with initial updating, and when it's finally idle then clear the log.txt file content and only then reproduce the issue, thus the log will contain only relevant information. Note that the log may contain raw communication between evolution and the server, thus make sure you'll not expose any private information, like user names, server names or even passwords. Also, if possible, could you try with some more recent version, please? I think of some Live CD with current development version, just to see whether it behaves better or not. The current development version is 3.1.90, released this Monday, but 3.1.5 is also good, as there were not done many changes in the IMAP provider.
thanks for the reply and i am sorry for the delay, busy couple of weeks. i tried the CAMEL_DEBUG but i am not sure what exactly i am looking for? i would rather not blast this bug report with a huge log file dump. if you can, please let me know what section/keyword/etc. i should be pasting here. thanks
Let's start with a basics, are you using IMAP or IMAP+ provider? There were some issues regarding flags fixed in IMAP+, thus maybe it's this. With a log, check for "UID COPY" (quotes for clarity only) in the log, then it may mark same UID as deleted, then it may refresh the folder content, when you enter it again. It shows read flags, if I recall correctly.
i am using the IMAP (not IMAP+) backend, as that is the only one which allows one to use an actual Trash folder, not the virtual Trash folder. i will create a new log file and look for the "UID COPY" and get back to you. thanks again for your help. peace
wayne, ping, any further update for the bug ?
Akhil, sorry for the delay. various issues and then waiting for new version to see if it was fixed evolution-2.32.3. unfortunately, issue still exists. i will put together the log file tomorrow and get that posted here (i know, i said that before, but i will actually do it this time ;). thanks for following up. peace
(In reply to comment #6) > sorry for the delay. various issues and then waiting for new version to see > if it was fixed evolution-2.32.3. unfortunately, issue still exists. Hi, the 2.32.3 is too old, and mostly unmaintained version. The best if you can test with current stable, which is 3.2.1, because there landed quite many changes between these two versions. You can also try with some live CD of a distro which provides this version.
that may delay things a bit: on Gentoo the best i can easily install is stable in portage is evolution-2.32.3, and available but masked is evolution-3.0.3. i will have to find a live CD image i can run in a virtual machine. i assume that would be a GNOME 3.x image? thanks for your help. i am downloading the GNOME 3.2 live CD image right now and will report back if the bug remains in Evolution 3.2. peace
OK, i was able to run Evolution 3.2 with a Sabayon 7 live CD. using the IMAP backend (to have an actual trash older), i setup account access and played around for about 30 minutes. in that time, the problem (i.e. deleting a message from the Inbox, then changing the current IMAP folder being viewed, then returning to the Inbox, and the message is not deleted) only happened once. however, it did happen and still seems to be an issue. does the original original request for the log info still apply with Evolution 3.2? if so, i will generate the requested debug info and post here. finally, is it possible that i am returning to the Inbox too quickly before the IMAP server has had a chance to move the message from the Inbox to the trash? however, if this was the case, i assume that the file would eventually disappear, which it does not do: i have to delete the file a second time to get it to move from the Inbox to the trash folder. thanks again.
Thanks for the update. The custom Trash/Junk folder works in a way that if you leave the folder then all your changes are stored into the server, and when any message is being marked as deleted or junk, then they are moved to the custom folder and deleted permanently from the source folder. IMAP protocol doesn't provide "delete one message" command, it only allows expunging of the whole folder, thus this is workarounded by "remove deleted flag from all other messages, expunge folder, remark message not for deletion with deleted flag again". This all takes its time, but you might not be able to enter the folder before this all is done. With respect of the log, yes, it will help to see what it is doing with the folder, what it writes and what it reads from it when you enter it. Once again, using CAMEL_DEBUG=all means showing also passwords and user names, server addresses and folder structures, not talking about quite chatty log. I'll be looking only for IMAP parts and operations on the offending folder, which you said is Inbox.
Created attachment 200242 [details] CAMEL log showing message deleted, left Inbox, returned to Inbox, message still there briefly, then is removed this is a CAMEL log showing an email message deleted, then i left the Inbox and viewed another folder, then returned to Inbox: the message was still there briefly, but then was removed to the trash. this i assume is expected behavior.
Created attachment 200243 [details] CAMEL log showing message deleted, left Inbox, returned to Inbox, message still there this is a CAMEL log showing the bug i am experiencing with the IMAP backend and custom trash folder: an email message is deleted, then i leave the Inbox and viewed another folder, then return to the Inbox: the message is still there. this i assume is NOT expected behavior.
Created attachment 200244 [details] CAMEL log showing message deleted after the message was already deleted once but reappeared when returning to view Inbox this is a CAMEL log showing the deletion of an email message that WAS ALREADY DELETED, but had reappeared when i returned to the Inbox (see attachment #200243 [details]). on this deletion (the second), the message was moved to the custom trash folder.
ahoy Milan e all, OK, i just posted 3 logs: 1. attachment #200242 [details] shows a message being deleted from the Inbox, it disappears from the Inbox, then i view another folder, then returning to the Inbox: the deleted message is there briefly but then is removed to the custom trash folder, which seems OK to me. 2. attachment #200243 [details] shows a message deleted from the Inbox, it disappears from the Inbox, then i view another folder, then returning to the Inbox: the deleted message is still there. this is the bug i am experiencing. 3. attachment #200244 [details] is just me deleting the message the was already deleted in attachment #200243 [details] (that had returned upon re-viewing the Inbox) i hope this helps. please let me know if you need more info, or if i happened to put anything private in my logs! i searched and did not see anything besides email addresses. thanks again. peace
another observation: i believe that this bug occurs with messages that are newly received (or possibly the most recent in the Inbox), since i have only been able to recreate the issue with files i had just sent myself (from another email account) then deleted immediately after receiving and reading. thanks.
one other question: is there a preferred/better supported IMAP backend between IMAP and IMAP+? i am trying to use IMAP since it supports custom Trash folders, which is necessary since i also access the same account via a webmail interface (HORDE/IMP) which uses a custom trash folder. perhaps IMAP+ will eventually support custom trash folders as well? thanks again for your help. peace
FWIW, I'm also seeing this with 3.0.3. Deleted messages also occasionally reappeared with the IMAP+ backend, but now that I switched to IMAP with a real trash folder, it's much more severe. Not sure it's the exact same problem with both backends though.
Created attachment 200440 [details] [review] Fix IMAP private message flag conflict After a lot of digging and head scratching in gdb, I found the problem: CAMEL_MESSAGE_IMAP_MOVED has the same value as CAMEL_IMAP_MESSAGE_RECENT, so 'recent' deleted messages are incorrectly skipped when collecting messages to be moved to the trash folder. This patch fixes the problem.
The issue with imapx is described in bug #654480. Good catch with the flag, that could be really painful to find this bug. Thanks for it.
Created commit 3ac86d1 in eds master (3.3.2+) Created commit b70b77d in eds gnome-3-2 (3.2.2+)
Thanks. As this was a regression in the 3.0 cycle, will the fix also be backported to the gnome-3-0 branch?
(In reply to comment #18) > Created an attachment (id=200440) [details] [review] > Fix IMAP private message flag conflict > > After a lot of digging and head scratching in gdb, I found the problem: > CAMEL_MESSAGE_IMAP_MOVED has the same value as CAMEL_IMAP_MESSAGE_RECENT, so > 'recent' deleted messages are incorrectly skipped when collecting messages to > be moved to the trash folder. > > This patch fixes the problem. thanks!
(In reply to comment #21) > As this was a regression in the 3.0 cycle, will the fix also be backported to > the gnome-3-0 branch? There is no plan to do an upstream release in 3.0.x version; I would rather ask your distro maintainer to include your patch in the package.
which version of Evolution includes this fix? i assume 3.2.2+ means any version after 3.2.2? thanks again for the help/fix. peace, w
(In reply to comment #24) > which version of Evolution includes this fix? i assume 3.2.2+ means any > version after 3.2.2? Yup, it's 3.2.2 and any later versions in 3.2.x release path.
OK, thanks again.