Bug 348040 - 4.14.6 Kontact / Kmail regression - ghost message breaks index and blocks function
Summary: 4.14.6 Kontact / Kmail regression - ghost message breaks index and blocks fun...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: MBox Resource (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR critical
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-21 07:29 UTC by stakanov.s
Modified: 2018-02-01 09:56 UTC (History)
0 users

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 stakanov.s 2015-05-21 07:29:47 UTC
create a dedicated folder in local folder
create a filter to apply to send messages by "from" "one of these verified" from a partial set of accounts, retrieve pop3.
create a preferred folder of that folder (list view)
receive a mail encrypted and signed pgp 4096/4096 and let it be filtered and appear in preferred folder. 
read it using preferred folder to select it. Close it down. 
shut down the system, reopen the system.
The mail will be still there. If you have as me defined a automatic archiving daily all local, then it will tell you: process aborted due to a problem in the respective folder. 
You go there and try to open the mail that was there before. It will not open (retrieving resource or similar with a bar running left and right). It will not open from preferred folder. It will show but now open in the preview window (as encrypted message).
It will show and correctly decrypt from the preview window if selected there (not in the normal local message list). When clicking on the mail, it will ask for password and correctly open. But it will not "open" right away if you click on the mail in preferred folder. 
Now, try to remove the preferred folder. The mail will be ghost, it will not open any more no matter what. It is lost. Try to join again the folder to preferred folder. The mail will show there but it is a ghost. 
In this state, it is impossible to do any backup from the hidden local folder. Either you have one or you have to save mail one by one by hand. 
If you go do terminal, run "akonadiconsole", go to the folder and see: the message purportedly is indicated with c.a. 213 kb or so... but it blocks everything. 
Tell akonadiconsole: clear akonadicache of that folder. The mail of that folder is screwed and lost (all!) but, the archiving procedure suddenly begins to work again. It finishes correctly. 
It is the possible to retrieve the old mail from a backup correctly (if you have one, naturally not the last received one).  If you do not perform this immediately, on the long run you may well loose all new mail of a period, as then more and more error seem to accumulate. 

For me that is a regression of the ghost messages and has to do with the filtering and the concomitant presence of the preferred folder. 

Reproducible: Sometimes

Steps to Reproduce:
1. create local dedicated folder in local, create a filter "from" pointing to it, create a preferred folder with list view.
2. receive a message RSA 4096/4096 encrypted/signed (european charset) and let it filter. Open it form preferred folder. 
3. close system reopen. Select the respective mail

Actual Results:  
In the occurrence (not regularly, you have to receive several messages) the message will be ghost in all but the preferred folder preview window. It will be total ghost if preferred is deleted. It will block in this status a local archiving procedure "all folders local". The process will culprit correctly the respective hit local folder. It is not possible to eliminate (put to trash) the respective message. 
When you clear akonadi cash then the mails of that folders are lost (all) but the archiving works again without error. The folder can now be put to trash or eliminated. (as said before that was impossible with either mail or folder). 

Expected Results:  
mail should arrive, be filtered, be readable and never corrupt serving as heroic testimony of our times for all the generations to come, up to the end of creation. As this is difficult, it is expected that index should not corrupt every few month or weeks randomly creating dataloss and despair as well as bitter tears and depression of the mail owner. (I take this with humour now  but be assured I did heavily rant on the poor opensuse-kde mailing list so I am quite serious, just my mood is better now). 

I put this to critical, I do every day backup. But that made me loose only that one mail. If I would have less space or be less paranoiac about the reliability of akonadi I would have had a big problem by now. 
This causes dataloss and if not noticed, extensive dataloss of mail.
Comment 1 Denis Kurz 2017-06-23 20:03:58 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 2 Denis Kurz 2018-02-01 09:56:04 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.