Bug 90623 - POP filter rules lost upon abnormal exit
Summary: POP filter rules lost upon abnormal exit
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: filtering (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
: 90889 140758 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-10-01 20:47 UTC by jellicle
Modified: 2009-04-04 19:43 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jellicle 2004-10-01 20:47:35 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Kmail pop filter rules are lost (erased) whenever Kmail exits abnormally, such as via a crash or even a fast shutdown.

Reproduce: Enter a few pop filter rules into Kmail.  Save them.  Kill Kmail quickly, such as with kill -9, shutdown -h now, or some similar method (File-Quit or Ctrl-Q will NOT exhibit this bug).  Reopen Kmail.  Pop filter rules are gone, reset to original state of nothingness.  I believe this is because Kmail saves the rules in kmailrc, and for whatever reason does not save them, or saves a copy of kmailrc containing everything except the pop filter rules, in these emergency shutdown situations.  Perhaps some sort of race condition.  I find this bug pretty much 100% reproduceable - if I shut down my machine without quitting kmail first, or kmail crashes for some reason, my (laboriously crafted) pop filter rules are lost.  The copy of kmailrc saved simply no longer includes any pop filter rules.

I occasionally see temporary files such as "kmailrcUIlLOb.new" saved in ~/.kde/share/config, which also indicates a race condition to me.

Expected behavior: I expect Kmail not to lose user settings and filters even in the event of an abnormal exit.  I suggest that such things (semi-permanent settings) not be stored in the kmailrc file along with the ephemeral, re-createable settings like the last-read state of each folder, especially if it causes those settings to be lost upon a crash.  At no time should a sudden exit of Kmail cause it to lose important settings.
Comment 1 Mike Unke 2005-01-29 21:42:38 UTC
Same problem here with a 1.7.2 from the SuSE-package.
Kmail does an abnormal exit (in my case while decrypting a message) and after a new start of Kmail every setting is gone. I even don't need to do a reboot to lose my settings.
That's annoying, because my pop filter is quite long.
Comment 2 Andreas Gungl 2005-02-05 21:06:52 UTC
*** Bug 90889 has been marked as a duplicate of this bug. ***
Comment 3 Andreas Gungl 2005-02-05 21:10:38 UTC
It's rather a bug than a wish. Mike, I would like to see if I can reproduce (Suse 9.2 and KDE 3.3.2 here), but I need instructions about how to initiate such an abnormal exit. Afterwards I would liek to check against the code for the upcoming KDE 3.4.
Comment 4 Janet 2005-02-27 20:10:26 UTC
It also appears in KDE 3.3.2 (Kanotix X)/KMail 1.72: The pop filters disappear  even without a noticeable abnormal exit - about every 3 to 4 times I restart the computer. Maybe KMail or one of its components is (invisibly) still active when I shut down the computer but I have shut down KMail and there were no icon of it left in the kicker tray. It's a very serious bug IMHO.  
Comment 5 Janet 2005-03-09 14:48:06 UTC
It exactly happens when I check mails, close kmail (and klick on the icon in the tray to completely close it) and after that shut down the computer. For me at that moment kmail isn't active anymore. But when I restart the computer and KDE and kmail - all pop-filters are gone, erased of ~/.kde/share/config/kmailrc. For I did know this would happen when I tested it today I backuped the kmailrc. Luckily I do not have to re-enter all pop-filters in the kmail dialogue, it "just" is enough to copy them to kmailrc and (important) to set "popfilters=" in section [General] to the current number of pop-filters (it is set to 0 after the filters have been erased) - otherwise the newly re-entered filter rules will be erased on kmail startup. So all of you kmail users out there always keep a backup of your pop-filter rules in a safe place.
Comment 6 Andreas Gungl 2005-03-28 10:49:45 UTC
I've tried for some days to trigger that bug on my system. But whatever I do to KMail (closing the session with KMail in the tray, killing KMail etc.), I never loose the POP filters.
Can you make sure that only the POP filters are lost in the kmailrc file? (This would be strange anyway, because there is no difference in writing the normal filters and teh POP filters AFAICS.)
Comment 7 Andreas Gungl 2005-03-28 11:10:46 UTC
Okay, it happend here just after writing the last comment. So there's a chance to reproduce and fix it.
Comment 8 Janet 2005-03-28 15:18:36 UTC
As I have written on 2005-03-09 only the pop-filters are erased and the counter for the pop-filters is set to 0 - nothing else (diff). Did you exactly try it this way?: fetch emails, close kmail with icon in tray, shutdown computer? Don't wait a few minutes between those actions, close it immediately after succesfully fetching mails, shutdown pc immediately after closing kmail. 
Comment 9 Andreas Gungl 2005-04-08 21:45:22 UTC
Hm, I somehow lost the state to reproduce the POP filter loss during a crash. The POP filters stay intact. I'm also not able to reproduce it via a shutdown. Perhaps my machine is to fast so that KMail writes it's config file properly while it's hidden in the middle of the writing of that file on slower machines. However this theory can't be backed by the implementation, because the data is written to a temp file which is afterwards renamed to the config file. But it's meant to be complete at that moment.
Comment 10 Janet 2005-04-09 07:06:46 UTC
My machine is a P4 2,6 (512 MB RAM) - wouldn't call that slow... But I really have to wait let's say 5 minutes after fetching mail before I can safely shutdown. BTW: I am using kmail integrated into kontact.
Comment 11 Janet 2005-04-22 14:22:37 UTC
I did not have this behaviour with KMail 1.8/KDE 3.4 - is it fixed or am I just lucky?
Comment 12 Andreas Gungl 2005-05-22 23:01:09 UTC
The chances to loose the filters are significantly lower, but as I had such a situation by myself with KMail from CVS, I better keep the report opened.
Comment 13 yuzyk 2007-01-27 01:49:29 UTC
I just found that KMail steps on Pop Filters in kmailrc at startup. When KMail crashed a few minutes ago, I figured I'd just copy my saved kmailrc Pop filter settings into kmailrc and restart and go. But no, the filters do not appear, and furthermore kmailrc is altered to delete them. Then I change permissions on kmailrc on root, just to see when KMail is writing kmailrc and it's right at startup because I get a dialog telling me permissions on the file are a problem. But KMail starts anyway, and even then there are no Pop filters even though the are in the untouchable kmailrc.

So, I suspect that kmailrc is read, Pop filters are stripped or forgotten, and then kmailrc is re-written, right at startup.

For some reason Pop filters have been a problem this way for many versions of KDE. Why are they treated differently from regular filters and all other KMail settings?
Comment 14 Pierre Zweigenbaum 2007-12-14 09:45:38 UTC
This happens to me from time to time too (kdepim-kmail-3.5.6-9mdv2007.1).
Note that when editing kmailrc to reinstate the pop filters, the line
'popfilters=0' in [General] must also be updated.
Comment 15 Thomas McGuire 2008-02-17 02:06:58 UTC
*** Bug 140758 has been marked as a duplicate of this bug. ***
Comment 16 Jaime Torres 2008-09-10 18:52:02 UTC
unable to reproduce killing -9 kmail, kontact receiving mail 
from imap, from pop3, idle, after modifying the pop filters... they are 
still there in 1.10.1 (kde svn trunk 857915)
Comment 17 jos poortvliet 2008-11-29 20:02:46 UTC
Unable to reproduce. KMail 1.10.90, KDE 4.2 beta 1
Comment 18 Michael Leupold 2009-04-04 19:43:34 UTC
I can't reproduce either using trunk r948809. Closing.