Version: 1.6.2 (using KDE KDE 3.2.3) Installed from: SuSE RPMs Whenever KMail exits uncleanly (system crash, segfault, kill -9, whatever), it leaves behind a lockfile in ~/.kde/share/apps/kmail/lock . Trying to start KMail if this lockfile exists currently (in release versions) brings up a big scary error message that most people don't know how to fix (just delete the listed file). The CVS fix to bug 60753 provides an option to delete the lockfile and continue. Most users, however, are unlikely to understand lockfiles or be able to make a good choice. Since the lockfile includes the PID of the "current" instance of KMail, shouldn't lockOrDie *first* check to see whether there's a copy of KMail running at that PID and nuke the lockfile without user intervention if there's not?
Related bug 112024 and bug 109637.
KDE-PIM bugs day: cannot reproduce with kmail 1.9.5, KDE 3.5.5 To confirm: start kmail, copy ~/.kde/share/apps/kmail/lock to /tmp/lock, quit Kmail. Copy /tmp/lock back to ~/.kde/share/apps/kmail/lock. Run kmail, it starts up cleanly and updates the lock file with its new PID. Existing lockfile with stale PID is now properly handled in KMail::lockOrDie() (kmstartup.cpp).