Luca Beltrame writes:
I can't reproduce your issue on PIM: that doesn't mean it does not exist, but rather that it's not a 100% always-failing case. You may also want to check if it happens on 16.12.1.
The issue, best I can tell, is with the maildir backend in conjunction with mail backends that download mails from the server to the maildir (POP3) plus filters moving the mails from such an inbox into other maildir folders. When mails get downloaded into the inbox, the filters apparently process them before they end up in the correct place, creating lots of duplicates and files staying in .../new instead of getting moved to .../cur in the process. This only gets worse over time and once you've got enough duplicates, the maildir backend just disconnects when kmail is asking for the content of a particular folder and goes sulking into a corner. Somehow the various agents step on each others toes and akonadi just lets them do whatever they want with abandon. The maildir structure is designed to allow for atomic operations on the mail files, but obviously at least one of the resources / agents doesn't use them. BTW, the most useful part of the POP3 implementation in KMail, namely that you could delete spam directly on the server without ever having to download them, was broken long ago. Luckily I don't have to use a 56k modem anymore. The comments from KMail devs at the time was that everything was working fine for them with IMAP and leaving the mails on the remote side. It seems that nobody tests the POP3 backends anymore in any useful form. I've specifically not moved to IMAP backends as at the time I tried them the filters were broken in other ways and were deleting email while trying to move them to the local maildir. Not sure if that still happens, but I don't really want to try with live mail accounts. As for fixing a broken maildir (make a backup of the maildir and the akonadi database first!): The fdupes thing mentioined a few days before should be your first stop. Then run 'akonadictl fsck', which likely will tell you about lots of duplicates, but doesn't actually give you an option to do something about them. For each maildir, you'll have to go into .../new and .../cur and remove each of the duplicates you find. Hilariously akonadi thinks you can have a duplicate of a non-existing file, so if that happens your best bet is to cp the deleted file from your backup to the maildir .../cur (not .../new) and delete it again until the fsck stops reporting that particular file as a duplicate anymore. I've had one that seemed to have had more then ten duplicates somehow. I don't know what happens if there's a duplicate reported that you don't have the file for anymore, since it didn't happen to me I guess it'd work to just use a different file (maybe even an empty one) with the same name to trigger the cleanup for that entry in the internal database. Once the fsck reports no duplicates anymore, move all files from .../new to their corresponding .../cur, then run fsck again and then vacuum. Then, switch all inboxes to manual fetch and switch off all filters that run on an inbox and instead run them manually (Ctrl-J) after the inbox download has happened (of course, sorting mail is what filters are for, so that description fit _all_ my filters). This ensures the mailbox download and the filter operation won't ever happen on the same time. So far this seems to have done the trick of keeping the maildir in some usable form. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org