Bug 125528 - Moving to IMAP folder while offline eats mail
Moving to IMAP folder while offline eats mail
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: evolution (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Malcolm
Depends On:
Blocks: 132991
  Show dependency treegraph
Reported: 2004-06-08 11:48 EDT by Kevin Otte
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-19 08:17:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:238 normal SHIPPED_LIVE Low: evolution security update 2005-05-19 00:00:00 EDT

  None (edit)
Description Kevin Otte 2004-06-08 11:48:43 EDT
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):

How reproducible:

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:
Comment 1 Rob Kearey 2004-06-11 02:11:39 EDT
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.

Comment 2 Rob Kearey 2004-10-11 19:40:55 EDT
Actually, I misread Kevin's bug report. Disregard comment #1.
Comment 6 Dave Malcolm 2004-12-15 22:17:25 EST
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
Comment 7 Dave Malcolm 2004-12-15 22:18:29 EST
(by "on Debian 1.4.6" I meant "on Debian, Evolution 1.4.6")
Comment 8 Dave Malcolm 2004-12-16 22:00:50 EST
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)
Comment 9 Dave Malcolm 2004-12-16 22:35:02 EST
I can reliably reproduce the bug in Evolution 1.4.5.  It appears that
it is indeed fixed in Evolution 2.0.3
Comment 10 Dave Malcolm 2005-01-06 17:18:36 EST
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
  This file appears to survive an Expunge, so it appears that we have
a way to recover messages lost due to this bug.
Comment 11 Dave Malcolm 2005-01-07 15:59:55 EST
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:
Comment 15 Tim Powers 2005-05-19 08:17:22 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.