From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: If you move a message from a Local Folder to an IMAP folder while in Offline mode, the message will not be present in either folder after returning to Online mode. Version-Release number of selected component (if applicable): evolution-1.4.5-1 How reproducible: Always Steps to Reproduce: 1. Mark an IMAP folder as an Offline folder 2. Create a message in a local folder 3. Go into Offline mode 4. Move the message from the local folder to the IMAP folder 5. Go into Online mode Actual Results: The moved message was nowhere to be found. Expected Results: The moved message should have been synced to the IMAP folder and appeared there in the message list. Additional info:
It does work, but only for messages marked as unread or important. http://gopher.quux.org:70/devel/offlineimap seems to be a viable solution for a workaround. I'll see if I can come up with a workable RPM for wider testing over the next week or two.
Actually, I misread Kevin's bug report. Disregard comment #1.
Also seen on Debian 1.4.6 as reported upstream here: http://bugzilla.ximian.com/show_bug.cgi?id=62140 (so presumably it affects FC-2 as well). Upstream closed that bug since the code was revamped for evolution 2.0
(by "on Debian 1.4.6" I meant "on Debian, Evolution 1.4.6")
Even worse: 1. Go into Offline mode 2. Move a message from one IMAP folder into another (with neither set to be offline folders in my tests) 3. Go into Online mode The message disappears altogether from Evolution, apparently not present in either folder. Checking with Thunderbird, it looks like the message has been lost from the server altogether. (this is with evolution 1.4.5)
I can reliably reproduce the bug in Evolution 1.4.5. It appears that it is indeed fixed in Evolution 2.0.3
I've done some further investigation of the problem, using comment #8 as a test case. It turns out that the moved messages are still present in the source folder, but have been flagged as deleted (and will get lost when you next Expunge). When you move messages whilst offline, the copy of the message in the source folder is flagged as deleted in Evolution's data structures, and a log of the move (and various other actions that were done whilst offline) is stored via the CamelDiscoDiary code in "~/evolution/mail/NAME_OF_MAIL_STORE/journal". A new copy of the message appears in the destination folder's local cache, with a temporary UID. When you go back online, the changed message flags are pushed to the server, and so the source message gets flagged deleted on the IMAP server. However, the actions logged to the journal file appear never to get played back, hence you don't get a new copy of the message in the destination folder. However, the locally cached copy of the message (with a temporary UID name) is still stored in ~/evolution/NAME_OF_MAIL_STORE/<path-to-folder-via-subfolder-directories>/tempuid-foo. This file appears to survive an Expunge, so it appears that we have a way to recover messages lost due to this bug.
I looked through the journal replay code, and found that the code to replay it bailed out early, reporting that the journal file was empty. It turns out that the file is fopen-ed with "a+" mode, and camel_disco_diary_is_empty uses ftell, which returns 0, despite the file being (in my test case) 33 bytes long. I added a fix for this (an initial fseek to the end of the file), but it caused a deadlock inside the camel code. I've now seen this upstream bug, which looks like the same behaviour; I will try to isolate the fix: http://bugzilla.ximian.com/show_bug.cgi?id=55618
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-238.html