GNOME Bugzilla – Bug 667576
Junk between messages after saving an mbox file
Last modified: 2012-06-28 13:01:28 UTC
Created attachment 204878 [details] an example of saving four emails from the linux-scsi mailing list. Note the huge amount of binary junk between emails 2,3 and 3,4 openSUSE 12.1; evolution-3.2.1-2.2.2.i586 Selecting three or more emails to save and doing save as results in the emails having a huge amount of junk characters separating them. This is a fairly recent regression because saving multiple emails worked in 2.x I've added an attachment from saving four emails from linux-scsi by way of example
Created attachment 204909 [details] [review] Recommended fix which gets a new buffer each time
The change that seems to have caused this is commit f0a011f941bab3f6ac7228be4e1bec86a0de0d2a Author: Matthew Barnes <mbarnes@redhat.com> Date: Tue May 17 19:50:33 2011 -0400 I the problem seems to be that the new use of g_seekable_seek() to rewind the memory buffer backed stream in e_mail_folder_save_messages_sync() doesn't reset the byte_array->len parameter properly, so we're carrying junk characters for subsequent goes around the loop. I tried adding complete truncates in there as well, but nothing works. The only fix is to get a new byte_array and basic_stream for each go around the loop. I'd say the true bug probably lies in g_seekable_seek(), but we need a fix for evolution now, so I'm requesting this patch be applied
CC'ing Matt as the initial commit triggering this was by him.
(In reply to comment #2) > I the problem seems to be that the new use of g_seekable_seek() to rewind the > memory buffer backed stream in e_mail_folder_save_messages_sync() doesn't reset > the byte_array->len parameter properly, so we're carrying junk characters for > subsequent goes around the loop. Actually g_seekable_seek() is working correctly, it's just the wrong thing to do here. I'm sure that's my bad. James has the right idea in creating a new stream each time, but if we use camel_stream_mem_set_byte_array() after creating the stream instead of camel_stream_mem_new_with_byte_array(), then the stream won't take ownership of the GByteArray and we can reuse it for each message (it's one of Camel's little quirks).
Fixed for Evolution 3.3.5 in: http://git.gnome.org/browse/evolution/commit/?id=df3495a6ec99d53beeaac6b9a2fde8dfd356c439 With credit to James for the solutions; I just tweaked it a bit.
*** Bug 671527 has been marked as a duplicate of this bug. ***
Any chance of backporting this critical fix to 3.2.3? Unable to resolve the extensive dependencies to move to 3.3.5. Don't have GNOME 2 so unable to resolve dependencies for lower versions. This is a serious bug. Evolution hangs and demands >100gb disk space. Would be great if I could export my email sometime before the next production release of my distro.
DT: Feel free to ask your distribution to provide a package with the patch for you. No 3.2.4 upstream release planned, sorry.
*** Bug 679037 has been marked as a duplicate of this bug. ***