Mailinglist Archive: opensuse-factory (807 mails)

< Previous Next >
Re: [opensuse-factory] PIM problems / Fixing a broken maildir (was: 1. KDE Applications 16.12 => 16.08 // 2. Only update to matured versions of KDE // trigger warning!)
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References