On Tuesday, 31 January 2017 16:12:01 GMT John Janus wrote:

Since I had no major issue with KDE Applications (including kmail/akonadi) in the last years, excepting the rather annoying time when kmail wouldn't parse ical attachments correctly, I'd suggest a repository containing the applications in a version deemed stable... For me the reason I chose to use Tumbleweed was to get the latest Plasma/KF/Applications without the hassle of constantly checking how the OBS repositories containing that are named this month.

I don't want to say “works for me and I don't care about others", I just think a rolling distribution should not stop rolling some packages due to a perceived “bug overflow”. Downgrading a package contains the risk of breaking user data due to configurations or data being changed/adapted by new releases. I don't know, whether this would be the case here.

Sincerely John

I have some sympathy for Alexander, I really do. As a long-time kmail user myself I know how frustrating it can be - I've had my share of catastrophic mail failures/losses through no fault of my own (almost exclusively after the introduction of akonadi). On the other hand, I also have to agree with John here. I don't think that holding back the KDE packages is the answer. Like John, I switched to Tumbleweed strictly because it was rolling release, and because I wanted to follow the upstream KDE as closely as possible. Just my "two cents", as it were. Kind regards, Huw

Am Mittwoch, 1. Februar 2017, 20:26:26 CET schrieb Achim Gratz:

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.

(@Luca:) Yes, of course, otherwise I'd have been happy. A bug may occur, but here this bug, which hits many users and has not been cleared within almost two months.

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.

Very good description what happens. Same here. I used filters to move incoming emails of a POP3 account into different folders. This is no longer working. The filtering process goes on for a long time, if it doesn't crash completely. I have no access to the new emails which are already inside the folders.

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.

fdupes showed after four weeks more than 10.000 duplicates and the process to eliminate them from within kmail (Ctrl + *) crashes after a short period of time.

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.

I'm behind a t-online account and they have a more or less working spam filter, so I didn't realise that.

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. Yes, obviously. And even if there is a severe bug, the kdepim people even don't communicate whether they care or not.

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.

To prevent loss of emails, yesterday I have created an IMAP account on my notebook for this email address here, but (!) I haven't deleted the POP3 account. I'm filtering on the server: all mailing-lists go immediately to folders on the server. In kmail, I've made something which is called server sided subscription (in German: serverseitiges Abonnement). So I avoid filtering POP3 emails mostly. On the other hand I'm getting the emails addressed to me and can keep them locally. I don't like the cloud. By the way, even IMAP makes trouble. I'm getting hundreds of complaints from the server: org.kde.pim.imapresource: Get metadata failed: "GetMetaData fehlgeschlagen, die Serverantwort lautet: A000580 BAD Error in IMAP command GETMETADATA: Value 1/1 of DEPTH is not numeric and positive or infinity . ( RFC 5464 Section 4.2.2 ) ( 0.000 + 0.000 secs ) . " I'll open a bug report for this (as if kdepim people had the time to care about bug reports).

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.

Yes, thank you for the description. I tried to delete the "Status O" lines using sed, which partially worked and then tried to delete duplicates using fdupes. But akonadictl fsck was unimpressed. The list of duplicates changed, but wasn't completely reduced to 0.

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.

Instead of copying I used "touch" with the filenames of the duplicates.

I've had one that seemed to have had more then ten duplicates somehow.

This part of akonadi is really broken.

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.

I hardly can avoid to make some cycnical jokes. My email system gave shelter to far more than 100.000 emails. I appreciate your help very much, but going this way is, ahem, time consuming ?!

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.

Impossible here. I won't spend time filtering emails. I already spent to much time with this mess. During the last weeks I realised that kdepim has been a huge issue for many, many users during the last three or four years. So many complaints, which never where addressed. You can see it here on Tumbleweed: When I suggested to stop delivering monthly updates of kdepim (=KDE Applications), Luca told me that this won't happen. I disagree after having a look at the monthly bug list of kdepim here: https://mail.kde.org/pipermail/kdepim-bugs/2017-January/thread.html If you go back in time, it's more or less the same every months. kdepim plainly is FACTORY and not ready for a rolling release. What I don't understand: The situation of kdepim probably has been known to all the professionel developers here. Why on earth has a working email system such a low priority? People love POP3, because they can save their emails locally after they get deleted on the server. And a 10 GB IMAP account doesn't react quickly, so you have to store them locally, if you don't delete them. Kind regards, Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org