GNOME Bugzilla – Bug 562529
Evolution didn't complete the folder move operation
Last modified: 2013-08-23 18:21:13 UTC
Evolution 2.25.2 (IMAP) Drag a folder from local to IMAP account and it didn't complete after more than 12 hrs. Folder has approx 8k mails. I can still see the folder in local folder tree but all the messages are strike out. Status bar shows "generating message list" and "storing folder". Gdb traces of evolution process
+ Trace 210297
I tried to close evolution from UI but it was not closing down also. I had to force shutdown
Could it be also due some performance hits, which are addressed in bug #558883?
I think they are unrelated. I need a closer look may be a bit later.
with actual trunk, which includes patch for the async fsync, it doesn't take so long, I tried copy (maybe move will be harder) with folder of 4810 messages, from imap to local, and it took approximately 1 hour, maybe a bit less. It's still too much, but is better. My HDD was performing a music all the time, poor little equipment. I would suggest something like freeze/thaw on db basis, like begin_mass_operation, end_mass_operation, which will start transaction on some higher level, which should help here. But I do not know how much possible it is from srag's point of view.
Milan, please look at bug 571408 also which i tried after fsync changes got committed. I feel there are still some bits missing.
After today's investigation, I'm afraid that we cannot do more here. I tried to play with a folder with ~4800 messages (~18MB mbox file), moving and copying from a local account to an IMAP account. It took approximately 2 minutes for the local IMAP, but the remote is much slower, which I believe is because of slow upload. There is no special call to fsync during this operation (except of timeout on update). The only thing I found is that the camel_db_add_to_transaction is called also out of transaction, at the exit of Evolution, for example, and that SQLite doesn't support nested transactions, which complicates things much. Also, sometimes, after this move, there is called 'call_old_file_Sync' function so many times (it's more than 500). I really didn't check why, but it seems like time, when you select folder, which isn't downloaded yet, and the first fetch is going to happen - no clues here, just an observation and a guess).
*** Bug 628866 has been marked as a duplicate of this bug. ***
See a different point of view in bug #628866
Closing as OBSOLETE since the investigation stalled and the stack trace is too old to be useful now.