Bug 405353 - Akonadi doesn't correctly assign "new" and "cur" mail within local-mail - deleted mail shows up again and again
Summary: Akonadi doesn't correctly assign "new" and "cur" mail within local-mail - del...
Status: RESOLVED DUPLICATE of bug 376032
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Maildir Resource (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-11 15:30 UTC by piedro
Modified: 2019-04-06 10:13 UTC (History)
2 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 piedro 2019-03-11 15:30:28 UTC
SUMMARY

In my kmail local mail folders, there is no mail shown as "new mail" in kmail. 
But within the .local/share/local-mail folder mails do not get moved correctly from "new" to "cur" subfolders. 

In consequence mails I delete reappear until I move them around manually with a file manager - which is not a solution and also doesn't work as reliable workaround since the maildir structure management of akonadi seems to be inconsistent. Some times hidden subfolder structures are created correctly, some times they seem not to be distributed correctly after additional subfolders to local mail in kmail are added.   


STEPS TO REPRODUCE
1. create a "spam" folder for example within Local folders 

2. let hte spam filters of kmail move spam to "Local Folders/spam" 

3. try to delete all mails in the "spam" subfolder


After switching to another folder  and checking back into "spam" many mails reappeared. Reindexing doesn't help. Marking everything as read before deleting doesn't work. 

Checking with a file manager some Mails are in "cur" some in" new" though there is no more new mail in kmail! 

Now though this is not a valid option I also tried just waiting for a while... hasn't worked neither. 

Deleting the mails with a file manager within the .local/share/local-mail is the only way I could get rid of the deleted mail for good. 

In this case kmail immediatly shows no more mails within "spam". 

Obviously akonadi doesn't 
- correctly distribute mail beetween "new" and "cur" 
- inconsistently handles maildir structures 
- recreates mails after they have been deleted 

This behaviour completely spoils the user experience with kmail. 

At the moment I have to manually maintain the maildir structure within .local/share after already having managed the mail in kmail. Doing it twice in different ways... 

p.s.: As I mentioned before it is not a good choice to put the local folders of kmail into ".local/share/local-mail". 

By using this location the mail in subfolders is not contained within the "local-mail" folder but in the hidden ".local/share/.local-mail.directory".  

Meaning that trying to backup local mail archives is not trivial anymore. also the documentation isn't correct on how to save your mail folder. 

Why not for example simply use the folder ".local/share/local-mail/local-folder/" as sane default. This way the user can be sure that ALL local mail within the maildir structure is contained in ".local/share/local-mail/". 

If for some obscure reason it is decided that this won't happen (though I do not see any downside) then please at least make sure the user is asked about the location of the "Local folders" in kmail BEFORE akonadi created the ressource at this location. 

thx, p.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux fully upgraded 

Kmail: 5.10.3
KDE Plasma Version: 5.15.2
KDE Frameworks Version: 5.56.0
Qt Version: 5.12.1

ADDITIONAL INFORMATION
Comment 1 Robert David 2019-03-13 12:21:04 UTC
I can confirm wired behaviour of moving between "new" and "cur".

I have different setup, fetching mail using mbsync and kmail is only client above these maildirs (I have multiple accounts).
Clicking on new mail will handle it correctly (move from new to cur). But marking a folder as read will do nothing (let say it will mark the akonadi cache as read but do not propagate it lower). So when I clean the directory cache from akonadi and let it resync, the messages would be unread. Other side effect is that it would not resync to server, but this is issue of my not common setup (I was tired of regular hangs of akonadi imap sync mainly from our unstable stupid company imap server).
Comment 2 Robert David 2019-03-13 12:26:38 UTC
Seems like duplicate bug is 376032. 

376032 - Emails not being moved from "new" to "cur"
Comment 3 piedro 2019-04-06 10:13:44 UTC

*** This bug has been marked as a duplicate of bug 376032 ***