Version: 1.9.6 enterprise 20070904.708012 (using KDE 3.5.7) Installed from: SuSE RPMs OS: Linux When kmail autosave function is activated, it does not save after the requested time. In fact, it does not save at all, nothing happens. Whether user tries 2mins, 5mins, 10mins autosave, it never works. Expected behaviour: autosave function should save a draft of the email after the requested amount of time. OS: openSUSE 10.3 64-bits
Please try a newer version, I think this bug has already been fixed.
Using kmail 1.9.50 under KDE4.0.3 Release 10 in openSUSE 11 Beta 1 64-bits makes no difference as opensuse 10.3 KDE 1.9.6: auto-save function does not seem to trigger. Is 1.9.50 after 1.9.6 (6 being smaller than 50), or .50 is equal to .5, therefore smaller than .6?
Trying kmail 1.9.50 under openSUSE 11.0 Beta 2 KDE4 64-bits and the autosave function does not save after the interval selected, nor does it afterwards.
Any changes so far? It still does not work on the 1.9.50. tnx
Tried with version 1.9.51 under opensuse 11.0 64-bits, KDE 4.0.4 >= 20080505 release 14 and that autosave function still does not save at all an email after the specified amount time the user inputs in the parameter of TOOLS/CONFIGURE KMAIL/COMPOSER/AUTOSAVE INTERVAL. It does not save even if waiting much longer than the specified amount of time.
I confirm this bug. KDE 4.1, Kmail 1.10.0, Gentoo x86_64
With Kubuntu Intrepid packages (kmail 1.10.1), the autosave feature often works for me. HOWEVER, there is at least one serious problem with the design of this feature. This can be revealed by doing the following (first, finish and send out any in-progress messages or save them as drafts, because otherwise you will lose all your work): 1. In konsole, navigate to ~/.kde/share/apps/kmail/autosave 2. Type "kontact &" 3. In kontact, start a new message 4. Wait for the autosave interval---you will see output on the command line when autosave executes 5. Examine cur/ for messages; you should see a file corresponding to your in-progress message (at least on Kubuntu, that is; from the above it seems this might not work for some people...) 6. Quit kontact. Wait a moment for it to really quit. Then restart kontact. Your in-progress message should pop up in a composer window, suggesting that all is right and good with the universe. 7. Quickly, in konsole examine the cur/ directory. You'll see it's _empty_. And there's nothing in new/ or tmp/, either. 8. Before the autosave interval expires, quit kontact. Wait. Restart it. Presto, you'll see that you've lost the in-progress message! Aside from this systematic way to replicate the problem, I should also mention that, over years of using kontact in KDE3, I've also lost in-progress messages after a kontact crash, even ones that had been autosaved previously. It's possible that these "bad" crashes always occurred in the first 1-2 minutes of starting kontact (and thus before the first new autosave), but my memory does not let me be sure of this. I wonder if it might be worth checking to see whether there is a brief moment in which the old autosaved files are deleted but the new ones are not written---if kontact crashes between those events, work is lost. So, to make autosave robust, kontact should: 1. at startup, stop deleting the files corresponding to autosaved messages, or execute autosave immediately after reloading any autosaved messages---that way if kontact crashes in the first minute or two after starting (something I've seen happen more than once...), the user doesn't lose data 2. execute autosave upon quitting (that way any changes that have been made since the last autosave are not lost) 3. in the middle of an autosave, insure that old autosaved files are never deleted until after new ones are written
I agree with you Tim. I just tried 1.10.1 in Kubuntu 8.10, I saw the autosaved file in the cur folder. However, reopening kontact did NOT bring up the in progress msg and guess what, you are right, I lost it. :) Of course it was a test, so no worries. This might not be a bug, I would agree with that. But we agree there seems to be an important concept flaw around the way the function works in kmail. That autosave function should work just like in Outlook, it should save under draft as an unread msg and it should stay there until you manually delete it from draft OR you send out the msg. That's it. Then if kmail crashes, you are protected from the last saved time and you can also close the msg window, ask for a save, then reopen it from the draft WITHOUT it being removed from draft. Currently if you open a saved drafted msg it will move it away from draft, so it crashes quickly, you lose the msg. Which happened to me the first time, cuz I did not notice it removed it. This semi-bug has received 40 votes so far, tnx to all the supporters. Bug (or concept of how to manage a draft, if this is not recognize as a bug) happens in Gentoo, openSUSE, Kubuntu and Fedora, so far. Can someone at KDE-KMAIL see what can be done or changed to the currently autosave concept? Tom? tnx
The actual bug is fixed, however we can keep this open for the bug mentioned in c#7 ff. This is still reproducible on trunk r948809.
Created attachment 37839 [details] Discard file
Since I haven't updated this report recently, I thought it would be of value to report that the issues in comment #7 are still present in KDE 4.3.2 (Kubuntu 9.10). Does anyone have information about whether this has been fixed in the upcoming KDE SC 4.4? (I don't have a spare machine/hard drive space to test it myself, so I rely on distributor updates.) Or is this the kind of issue that the developers intend to fix via the transition to Akonadi? Best, --Tim
Comment on attachment 37839 [details] Discard file Content deleted
SVN commit 1093923 by tmcguire: Don't remove the autosave file after recovering. It will be properly cleaned up in cleanupAutoSave() anyway, which is only called after successful sending or saving as draft. This fixes mail loss when KMail crashes before the first autosave kicks in, after recovering a message. BUG: 159634 MERGE: 3.5, trunk M +0 -4 kmcomposewin.cpp M +22 -17 kmkernel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1093923
Thanks, Thomas! I'm looking forward to this!
SVN commit 1094756 by tmcguire: Crossport r1093923 by tmcguire from the KDE 4.4 branch to the enterprise35 branch: Don't remove the autosave file after recovering. It will be properly cleaned up in cleanupAutoSave() anyway, which is only called after successful sending or saving as draft. This fixes mail loss when KMail crashes before the first autosave kicks in, after recovering a message. CCBUG: 159634 MERGE: 3.5, trunk M +0 -3 kmcomposewin.cpp M +24 -17 kmkernel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1094756
Thomas, is there any chance the fix to this bug caused the following new one? https://bugs.kde.org/show_bug.cgi?id=236229 Or is that an independent issue? While the message is not deleted, you have to descend to the command line and your .kde directory to discover that. So the net effect, for many users, is the same. (For me, the current situation is an improvement because there is no real data loss.)
> Thomas, is there any chance the fix to this bug caused the following new one? > https://bugs.kde.org/show_bug.cgi?id=236229 > Or is that an independent issue? Yes, that is an independent issue, which should be fixed now.