Red Hat Bugzilla – Bug 125528
Moving to IMAP folder while offline eats mail
Last modified: 2007-11-30 17:07:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
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):
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.
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:
(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")
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
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
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:
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.