GRYS Software

I finally restored all my mailboxes, after an encounter with akonadi.

Background story: I am an kde user from version 3.0 and a kmail user since then. It happen that in about 10 years I accumulated some thousand of mails, about 35000, from various mailing lists and projects I follow/followed plus my personal emails. So aside all the mailing list messages, there are about one thousand personal mail that I cannot lose (yes, I backup my data of course ) and until kmail 4.6.x I never had a problem while upgrading.

Now enter kmail 4.7 and akonadi and let the nightmare begin.

For some reason the kdepim developer decide that all the personal information of the user should be saved in a database using akonadi. Nice approach, if it only works.

I see the logic of the decision: if I can store all my personal data in one place and I build a layer to manage them, every application that need to know, for example, my email address just need to call this layer and ask for it, without the necessity to reimplement some type of mechanism to store the information. (I think that akonadi is a lot more, but, as I understand, it basically do this) But you must build a layer that work really well.

After the upgrade to kdepim 4.7, the first “stable” release of the suite to use akonadi as core, I find myself with a system where I basically am not able to use kmail  in the way I used to do, run it after the login and close it just before the shutdown, and luckily I just use kmail and not for work related projects.

There are a number of problems I run into, but these seems to me the worst:

• after the upgrade from kmail 4.6.x and the conversion of the data, kmail itself crash on start. Why ? No reason, or better, wrong conversion
• after recreating the akonadi db, things seems better, the mails are where they are supposed to be and I can read them, but wait, why the system is so sloppy ? After running “top” for 10 seconds the reason is clear: the load average is between 3 and 4, main reason the akonadi agents.
• why akonadi download the mail even if kmail is not running ? Answer: because the pop3 agents of akonadi, by default, are active also if kmail is not running. The feature is a good idea, but IMHO it must be enabled by the user, not to be enabled by default and without telling it to the user
• where are saved the mails ? Why it decide that is must be a certain directory that must not be visible to the users  ? (something like .local/share/.local-mail-folder/.mailbox) How can I backup my mails if I don’t know where they are ? Let the user decide where to put his mails is a so bad idea ?
• ok, I deleted the old db, copied the mail in a backup folder and switched to posgresql, a better database. Now it is time to import them, but wait, where are now my emails ? Answer: is some hidden directory.
• I recreated again my db, configured  a correct local mail folder agent, but where are the mails ? Why the local agent cannot just read the files in the directory ?
• after that, I finally imported the old mails, using a second local agent, and now I’d like put every mail in the appropriate mailboxes, right ? Wrong, just filtering about a thousand messages imply about 10 minutes of work and not always the process ends. Let imagine how many time if I filter all my mails. And just for comparison, Claws mail filter the same amount of messages with the same filter rules in about 1 minute. This can also be a problem of kmail itself, since it seems that it has something to do with the message list refreshing for each message moved
• why akonadi need about 20 or more database connection also if there are just 5 or 6 agent configured, some of which are not running ?

These are just the worst, as I said, but there are a number of minor problems that I don’t write down that are really annoying (one for all: after the conversion, kmail does not send mail anymore, until the agent are recreated)

Now, I am not in the position to tell anyone that he did and orrible work, of course the KDEpim developers are far better than me and they do something, nor I have a solution or the time to work out a solution, but reading forums give the impression that the kdepim developers made the same mistake the kde developers done with the release of version 4.0 of KDE, they release a software stack that is far from being stable and usable on the day-by-day work. (Look, after years where I was able to run kmail and make my work with it open, often on low-end machines, I find intolerable that on a decent machine I cannot do it anymore)

The downside of this “akonadi nightmare” are that I temporarily switch to Claws mail, loosing the KDE integration, and I loose about 2 weeks of my spare time to try to work out a decent solution and recover the mess.