(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.4 (using KDE 3.0.0 ) Severity: crash Installed from: compiled sources Compiler: gcc version 2.95.3 20010315 (release) OS: Linux (i686) release 2.4.17 OS/Compiler notes: I got a complete X lockup but was able to kill X from another computer. But I had an instance of KMail open and that was shut down uncleanly too. After restarting X KDE and KMail KMail crashed very often on selecting folders (All local maildir folders). I fixed it by quitting KMail and deleting all hidden files in my ~/Mail folder. e.g. find ~/Mail -name '.*' -type f -exec rm "{}" \; Then I restarted KMail and it rebuilt its indexes; from then on KMail worked stable as always. So maybe KMail should be more tolerant for corrupted index files or index files that do no match the real directory contents. Maybe even rebuild all local indexes on restart when KMail discovers it has had an unclean shutdown? (Submitted via bugs.kde.org) (Called from KBugReport dialog)
This seems to the appropriate place to write more about index corruption. Related Bugs: 50218 57748 (my old one) Is there a way to have KMail check the mail folders against the index files for discrepancies? It could be automatic, or there could be a UI for it. My push for something like that (even a UI for removing and rebuilding index files) is that, for new users, opening a terminal window and typing magic commands isn't extremely friendly. If someone claims to have lost messages, it would be easier to say 'click the rebuild button.' Another idea would be for KMail to touch a file in a directory (under Mail, Maildir or the .kde tree) when KMail is open. When KMail closes, the file could be deleted (or a parameter changed from 1 to 0 in kmailrc) after the index files are written to. If KMail starts and finds that the file or parameter says KMail is still open (i.e. did not complete the clean shutdown), it could rebuild the index files. Sometimes it is easy to forget that KMail is running when you remotely log in and use a text-based client (which gets into Closed Bug 45694), or sometimes X will crash (or KMail might crash one day). Doing so gives the appearance of lost messages, which is bad for a new user. Again, a check or a simple UI could save some time and worry for users. For remotely shutting down kdm, I have found this to work. It will logout users cleanly (i.e. have KMail properly shutdown). dcop --all-users ksmserver ksmserver logout 0 2 0 (My system: Debian sid, KDE 3.1.2 and KMail 1.5.2)
Subject: Re: be more tolerant when index files get corrupted Hi Doug Ward, On Wednesday 09 July 2003 02:03, you wrote: > ------- You are receiving this mail because: ------- > Another idea would be for KMail to touch a file in a directory (under > Mail, Maildir or the .kde tree) when KMail is open. When KMail closes, > the file could be deleted (or a parameter changed from 1 to 0 in > kmailrc) after the index files are written to. If KMail starts and > finds that the file or parameter says KMail is still open (i.e. did not > complete the clean shutdown), it could rebuild the index files. I think this is the best option. I would not like to have an UI for some internal KMail household that it should be able to do on itself. regards, Wilbert
Not sure if this is the place for this comment, but this seems to be the best place to report a problem I had today that was immensely embarrassing. For some reason when I shut my notebook down last night, my Outbox Index became corrupted. When I started up KDE this morning, I went to grab a cup of coffee and returned to find a notice that the the index on Outbox was corrupted and would be deleted and I would lose some flags. In the meantime my entire outbox had become unsent and was spewing old messages out onto the net. Some of my coworkers received 90+ old emails from me, but worse than that many of my company's customers received old emails from me. I sent everyone a personal apology which was graciously received. I'd like to suggest that outbox NEVER be able to resend old messages.
*** This bug has been marked as a duplicate of 63218 ***