Red Hat Bugzilla – Bug 601682
Already-sent mails recovered in composer after crash/restart
Last modified: 2010-11-04 05:46:55 EDT
When composing an email in Evolution, it creates ~/.evolution/.evolution-composer.autosave-XXXXXX files. When I _send_ the email, it should delete those.
So when even Evolution crashes and restarts, I end up with a bunch of composer windows with mails I'd already sent.
This seems to happen after a clean shutdown/restart too.
I can confirm on this.
With F12, Evolution also used to crash/restart randomly, but at least it did not repeatedly propose to "recover" an already sent message.
As a side note, on F12 I tried to explore the reason for these crashes; abrt re-installed half of my system with debug-enabled versions (evolution, gnome, glibc etc.) and still failed to complete a crash report. With F13, I'm not going to waste my time again.
This seems to have gone away with the latest Fedora update.
Assen, please re-open if you can reproduce with evolution-2.30.1-8 and other current updates.
I'm afraid the problem is still here.
As described by David Woodhouse, with some emails (roughly 1 in 10-20 mails; haven't spotted a particular pattern like HTML, attachments...), Evolution sends the mail, does not remove the autosave file ~/.evolution/.evolution-composer.autosave-XXXXXX, then crashes, restarts and prompts to recover the already sent message.
[root@cfo .evolution]# rpm -qa | grep evolution
System is F13, installed from LiveCD, all available updates applied, file system is ext4. If I can help any further with debugging, please, let me know.
Thanks for a bug report and updates. I guess it's also related to changes in , though they may not influence this behaviour much too. Changes from  are applied in evolution 2.30.2, thus please give it a try when it'll pass the update process in Fedora. Thanks in advance.
Updated to 2.30.2:
[root@cfo ~]# rpm -qa | grep evolution
The problem (random "Do you want to recover..." message) is still here. The interesting thing I only recently noticed: the message pops up only when switching to Evolution from some other task (I often use Alt+Tab and that's when I hit it). Moreover, there is no sign of a crash in Evolution (abrt is silent and it does complain when something else crashes). Could it be some other, maybe minor bug with the tmp file not being deleted upon sending the message and then, on switching back to the task, the GUI "sees" it and decides the message needs recovering?
If I can help further, please,let me know.
reopening per last comment. Might be just some coincidence, with all that asynchronous draft saving to the local disk on the first look. Are you sending the message or also closing it? And how long is the message opened before you send it? I mean, whether is the autosave file created or not before you send. The timeout for saving is about a minute.
Thanks for re-opening.
Indeed, the problem seems to only happen if the message has been manually saved as draft (Ctrl+S). I usually type my emails in the message windows, so I often hit Ctrl+S to keep a draft. When the message is ready, I use Ctrl+Enter to send it. When I go back to the main window, I'm greeted by the infamous "Do you wish tor recover..." message.
Oddly enough, the problem does not appear if I only rely on the autosave of Evolution. (It's just that I'm not certain how reliable it is; on the other hand, I sometimes have to save drafts between sessions, or start a draft in the office and complete it at home etc.).
If I can help further, please, let me know.
I can reproduce this with 2.30.2, with steps:
a) open composer, write some text to body and such
b) wait until it creates an autosave file in ~/.evolution
c) modify message body again, and use Ctrl+S to safe a draft
d) wait another minute, see no update on the autosave file (by time/file size)
e) modify message body and send it
Result: autosave file is still there
But when I try the same on actual git master (just before 2.31.6) then the autosaved file is properly removed.
The bug seems gone in Fedora 14, evolution-2.32.0-2.fc14. Any objection to closing the report?
Thanks for testing. Not from my side, and it's true that there were done couple changes in this area in 2.32.0. I'm closing this for David, but feel free to reopen if you face with 2.32.0 or later.