http://bugzilla.opensuse.org/show_bug.cgi?id=969675 Bug ID: 969675 Summary: Kmail pop filter amnesia and an apparent race condition present. Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Major Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs@opensuse.org Reporter: stakanov@freenet.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- KDE 4.4.17 KMAIL 4.14.10 Plasma 5: 5.5.4 QT 5.5.1 interface language Italian. This is a default installation of Leap 42.1. As Kmail in the default with Leap is held (rightly I would say) at version 4.14.10 this applies KDE 4 and Kmail running on it. However in the thread I did open in opensuse-KDE mailinglist another user complains that this is also true in TW for a pure plasma 5, framework 5, kmail5 installation with the very same symptoms. In my case: First aspect: when opening the user A, and setting Kontact to automatic start up, and if you put: check mail on start up, or if you click on check for mail right after the program started, filter will fail. The mail will be retrieved, it will be all put into the default folder of the respective account. If you select the folder and go into the menu and choose: folder: apply all filters to that folders, then the mail is filtered and distributed correctly. But, new mail will again not be filtered at all. This will apply to all accounts present. Now, if you logout and login again of that user. Then the filers will work now, no matter if you do respect the wait period or not. That is why I speak about a race condition of something starting up and not being ready when requesting new mail. Second problem: this issue is not without consequences on the filter listings. You will be prompted sooner nor later (normally on every start-up by another filter) with a window telling that for the filter X Kmail does not find the account. You are asked to choose ... but the list is empty. Now, if you click on the first line of the empty window you can actually change the grayed out status of the OK button to normal. And press O.K. and for now you are done. In about 30% (estimated) of this events you loose the filter in question. It is deleted of the filter lists and does not exist any more. If you click on cancel when this window appears you DO loose that filter immediately. Sometimes two filer are hit, so two separate windows to confirm pop up one after another. With the time you will loose at least half of all your filter. You may recreate them, but still for unknown reasons some vanish, and some have this problem. I have noticed also a slight dependency on one specific settings: if you have let us say about 6 mailboxes with pop with the same numbers of accounts, then, if you set the filter to be applicable to that specific account and not to the others, this filter will be hit much more frequently with this "cannot find account of filter" dialogue. Once the "amnesia" started it will "cycle" through and loose one by one a filter in the list (direction generally from top to bottom - without guarantee, it sometime can hit in the middle of the list). In this cases you may not be presented with the little window complaining not to find the account. You will just loose the filters one by one. Now let us speak about the dependency of this with "waiting". If you start up the user A with kmail in automatic and a) either open another user and then return to kmail to check mail. Or b) you do wait at least about 40 seconds to 1 minute usually the filter never fails. But it fails always and repeatably triggered by immediately asking for mail. Then the filter does not work and will not work up to logout/in again as stated. As this bug is loosing data (filter setup with a lot of care) it is quite annoying and may also ruin filter collections of users. -- You are receiving this mail because: You are on the CC list for the bug.