(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: KDE 3.0.0 Severity: normal Installed from: RedHat RPMs Compiler: Not Specified OS: Linux OS/Compiler notes: Not Specified kmail highlights folders that have new email This highlighting goes wrong when kmail is opened unless it was previously closed cleanly. I have seen this after power was lost while kmail was running and also after killing kmail with SIGKILL It appears that kmail will not highlight folders which contain unread email that was received before the unclean shutdown. the folder is displayed as if it contains no unread email. clicking on one of these folders in the folder-list panel will 'fix' the problem. The folder is immediately highlighted in the folder-list panel it shows the correct number of unread messages and the unread messages are displayed in the message-list panel. This is with maildir mailboxes. (Submitted via bugs.kde.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 26 June 2002 23:30 tdickenson@geminidataloggers.com wrote: > kmail highlights folders that have new email > > This highlighting goes wrong when kmail is opened unless it was > previously closed cleanly. I have seen this after power was lost > while kmail was running and also after killing kmail with SIGKILL > > It appears that kmail will not highlight folders which contain unread > email that was received before the unclean shutdown. the folder is > displayed as if it contains no unread email. The reason for this is that KMail caches the number of unread messages. If KMail crashes this cache can get out-of-sync with the real number of unread messages because the cache hasn't been written to disc before the crash. The solution would be to recalculate the number of unread messages for all folders after a crash. But: 1.) How do we know that KMail crashed the last time it was executed? We have a lock file which is created when KMail is started and deleted when KMail is quit. If the lock file is present but no KMail is running (on the local machine) then KMail either crashed the last time or another KMail is running on another machine. How do we know the difference? 2.) Recalculating the number of unread messages for all folders takes a lot of time if the user has many big folders. Therefore unnecessary recalculations have to be avoided. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Gj+aGnR+RTDgudgRAjaiAJ9iIdQDDz9SUf1fQQQ48SF2WXEzlACeMGPM O9f8ECchugqYp+M8yrDF0Tw= =6ryE -----END PGP SIGNATURE-----
On Wednesday 26 Jun 2002 11:26 pm Ingo Kl=F6cker wrote: > 1.) How do we know that KMail crashed the last time it was executed? > We have a lock file which is created when KMail is started and deleted > when KMail is quit. If the lock file is present but no KMail is running > (on the local machine) then KMail either crashed the last time or > another KMail is running on another machine. How do we know the > difference? Could the value in the cache file be removed when handling incoming mail? W= hen=20 starting up kmail would have to scan only those folders which do not have = a=20 valid cached value. > 2.) Recalculating the number of unread messages for all folders takes a > lot of time if the user has many big folders. Therefore unnecessary > recalculations have to be avoided. Why not always write the cache file after it has finished checking mail? Th= at=20 greatly reduces the time window in which kmail can crash and cause a proble= m.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 27 June 2002 11:06 Toby Dickenson wrote: > On Wednesday 26 Jun 2002 11:26 pm Ingo Klöcker wrote: > > 1.) How do we know that KMail crashed the last time it was > > executed? We have a lock file which is created when KMail is > > started and deleted when KMail is quit. If the lock file is present > > but no KMail is running (on the local machine) then KMail either > > crashed the last time or another KMail is running on another > > machine. How do we know the difference? > > Could the value in the cache file be removed when handling incoming > mail? When starting up kmail would have to scan only those folders > which do not have a valid cached value. Good idea but... (see below). > > 2.) Recalculating the number of unread messages for all folders > > takes a lot of time if the user has many big folders. Therefore > > unnecessary recalculations have to be avoided. > > Why not always write the cache file after it has finished checking > mail? That greatly reduces the time window in which kmail can crash > and cause a problem. Because the cache file would have to be written every time the number of unread messages changes e.g. after checking for new mail after manual filtering after selecting an unread message after marking a message as unread etc. Nevertheless we will try to find a solution for this problem i.e. write the cache more often. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9G5wbGnR+RTDgudgRAoEyAKC110m/Q8YNaDgzpKcS5k7N8cMT1wCfcTEC DrLsMSlHKxfFRGsOVWtwc6I= =X/4u -----END PGP SIGNATURE-----
kmail shouldn't crash in the beginning, handling that case is minor because of that :)
I am also interested in reporting this issue. In addition to unread message counts being messed up, sometimes "phantom" items appear in my outbox. These items really do not exist on the drive, and must be deleted manually. Would it be possible to write some kind of key or something when kmail is shut down cleanly, and then check for the non-existence of that key? Something similar to what was mentione earlier - check for a crash on startup.
Revisiting this issue (I'm going through all my old bugs...): Now we ask a user when the lockfile exists, can we key off that to reload the cache file? (See comment #2) If a lock file exists, we ask the user if another instance is running, or if they want to delete the lock file. If we delete the lock file, then we can also regenerate the cache.
Is this bug still present in a recent KDE version, such as 3.5.8?
I am assuming that due to comment #6 and the lack of response, that this issue is resolved. Closing the bug. Please re-open if there is still a problem.