GNOME Bugzilla – Bug 512798
Dataloss when remote server disconnects prematurely
Last modified: 2009-11-24 12:47:33 UTC
Forwarding this from a downstream bug report: http://bugzilla.redhat.com/show_bug.cgi?id=286421 Description of problem: When a message is moved between IMAP folders (on one server or between two servers) and the destination server disconnects for some reason during the transfer evolution removes the email from source folder anyway. This is severe dataloss bug. Version-Release number of selected component (if applicable): Happens in all evolution releases since at least FC6 till rawhide. (Btw if you combine evolution with the dovecot in rawhide which crashes frequently on large Maildirs, you can reproduce this very easily, but it is not dependent on the exact IMAP server, it will happen with different servers on network errors etc...) See also bug #446276 and #436802 Followup comments: Comment #2 From Matthew Barnes (mbarnes@redhat.com) on 2007-12-11 16:42 EST Moving messages on an IMAP server actually means marking the message for deletion on the source folder and copying it to the destination folder. In the times this has happened to me, I can usually find the message in my Trash folder and undelete it from there. It then shows up again in the source directory. Comment #3 From Tomas Mraz (tmraz@redhat.com) on 2007-12-11 17:20 EST Yes, but if you have filters which move the messages automatically you might not notice that some message was deleted and didn't appear on destination. So you don't know that you should look for it in trash.
dataloss -> blocker.
response = camel_imap_command (store, source, ex, "UID COPY %s %F", uidset, destination->full_name); if (response && (store->capabilities & IMAP_CAPABILITY_UIDPLUS)) handle_copyuid (response, source, destination); camel_imap_response_free (store, response); if (!camel_exception_is_set(ex) && delete_originals) { for (i=last;i<uid;i++) camel_folder_delete_message(source, uids->pdata[i]); last = uid; } Only if the copy is success the message is marked as delete. But there is way in the response parsing, that returns NULL without a exception set. Is there any way this could be easily reproduced, so that I can just play with my fix?
Srini, if you use a VPN connection for a mail account at Novell this is pretty easy to reproduce. Red Hat's VPN loves to drop connections so I see this a lot. I can reproduce this as follows: 1) Select a bunch of scratch messages on your company email account. Note how many you've selected. Should be enough that it will take a few seconds for the transfer to complete. 2) Drag the selection to an empty folder also on your company email account to start the move process. 3) Immediately disconnect your VPN connection. Wait a few minutes for sockets to timeout and error messages to appear. 4) Verify that not all the selected messages are in your destination folder. 5) Verify that /all/ of the selected messages in your source folder have been marked for deletion. User must take steps to undelete the messages before they're expunged. This kind of thing also happens to me when my VPN connection drops while I'm composing a new message. Hit send, composer closes and the message never shows up in my Sent folder or anywhere else.
Step 3.5) Reconnect to your VPN, of course.
see also a Debian report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422800
This had been covered by fix in bug #349870, where I'm marking this as a duplicate of that older one. Just note that bug #573240 is a result of those changes, but it doesn't break functionality of the fix. *** This bug has been marked as a duplicate of bug 349870 ***