# Migration zu kmail2

## l3u

Jetzt mal im Ernst: hat irgendeiner von euch es geschafft, seine bestehende kmail-4.4.11.1-Installation nach kmail2 zu migrieren?!

Ich hab es jetzt schon bei jedem einzelnen neuen KDE-Release versucht und bin jedes einzelne Mal gescheitert. Das Spiel ist immer das selbe: Der Migrator schlägt fehl. Es werden trotzdem einige Einstellungen übernommen, aber keine alten Mails. Dann versuche ich, meine bestehenden Mails zu importieren. Entweder, indem ich Akonadi ~/.kde4/share/apps/kmail/mail als KMail-Maildir-Resource beibringe und dann in die lokalen Mails kopiere oder indem ich die Mails per kmailcvt importiere.

Das Ergebnis ist immer das selbe: es funktioniert nicht, ich bekomme merkwürdige Fehlermeldungen, irgendein Akonadi-Prozess hängt sich auf (100 % Auslastung eines Prozessorkerns), etc., etc. Wenn tatsächlich irgendwelche Mails importiert werden, dann sind sie teils zwar unter ~/.local/share/local-mail bzw. ~/.local/share/.local-mail.directory zu finden, aber nicht alle – wo bitte speichert kmail dann die Mails? Nur im Akonadi-Cache oder was?!

Kann man überhaupt irgendwo sehen, was Akonadi, Virtuoso, Nepomuk und wie sie alle heißen gerade tun oder nicht tun? Ich sitz davor und warte ab, ob was passiert, ohne zu wissen, was gerade unter der Haube abgeht – das ist wie bei Windows früher :-(

Mache ich irgendwas komplett falsch? Oder ist das normale Benutzen von Akonadi und eine vernünftige Migration auch bei KDE 4.8.3 immer noch nicht möglich?!

----------

## toralf

 *l3u wrote:*   

> Jetzt mal im Ernst: hat irgendeiner von euch es geschafft, seine bestehende kmail-4.4.11.1-Installation nach kmail2 zu migrieren?

 Nein.

Deswegen bin ich seit 2 Monaten auch auf Thunderbird umgestiegen.

----------

## l3u

Na gut – so lang KMail 4.4.11.1 da ist und funktioniert, sehe ich keinen Grund, ein anderes Programm zu verwenden. Es läuft ja einwandfrei, die Misere hat ja erst danach angefangen.

----------

## boris64

Selbige Probleme hier, auch ich benutze immer noch kmail-4.4.11.1  :Sad: 

----------

## franzf

Interessant - ich bin mir zu 100% sicher, dass ich vor einiger Zeit gelesen habe, ab kde-4.8 wäre der migrator nicht mehr nötig, da die Entwickler eine kmail1-compatibility-resource mitliefern würden (oder zumindest die imap, pop, ... resourcen kompatibel mit kmail1 wären). Oder war das erst 4.9?!? Oder hab ich das geträumt? (Kann ja alles sien)

----------

## l3u

Da war was … aber vielleicht meinen die, dass man jetzt bei Akonadi eine KMail-1-Ressource anlegen kann? Nicht, dass das vernünftig funktionieren würde …

----------

## toralf

 *l3u wrote:*   

> Na gut – so lang KMail 4.4.11.1 da ist und funktioniert, sehe ich keinen Grund, ein anderes Programm zu verwenden. Es läuft ja einwandfrei, die Misere hat ja erst danach angefangen.

 +1.

Bei mir kamen in all den Jahren Wünsche auf, die in KMail 4.4x eben nicht mehr integriert werden würden. Zusätzlich hat mich allein schon die Notwendigkeit von Akonadi & friends zunehmend gestört - und in die Arme der Konkurrenz getrieben.

----------

## l3u

Akonadi ist ja an sich eine super Idee – dass das Speichern von E-Mails GUI- und Plattformunabhängig von einem Tool erledigt wird, das nur dafür da ist und jede Anwendung auf den selben Datenpool zugreifen kann finde ich vom Prinzip her genial. Nur funktionieren müsste es halt …

----------

## l3u

So, nochmal ein anderer Versuch …

Ich hab jetzt mal auf KMail2 aktualisiert und _nicht_ versucht, meine alten Mails zu importieren. POP3-Konto wie vorher eingerichtet und E-Mails abgeholt. Auf dem Server waren 1848 E-Mails, die jetzt auch alle schön im Posteingang liegen. Gut, manche will KMail nicht als gelesen markieren, wenn ich draufklicke, aber nichts für ungut.

Jetzt aber das merkwürdige (also zumindest ich finde das merkwürdig): Wo bitte sind die E-Mails?!

~/.local/share/local-mail und ~/.local/share/.local-mail.directory (eingerichtet als „Local Folders“) sind vollkommen leer:

```
tobias@skoni share $ find local-mail .local-mail.directory -type f | wc -l

0
```

In ~/.local/share/akonadi/file_db_data/ sind einige Dateien zu finden, die offensichtlich E-Mails sind, aber:

```
tobias@skoni file_db_data $ ls -1 | wc -l

789
```

Wo bitte sind die 1059 anderen E-Mails?! Und warum lege ich überhaupt eine lokale Mailbox per Akonadi an, wenn darin faktisch nichts gespeichert wird? Wie soll von meinen Daten ein Backup machen, wenn ich nichtmal weiß, wo sie sind?

 *http://blogs.kde.org/node/4503 wrote:*   

> In case of POP3, the mails is stored immediately after download in a local maildir folder. The actual place of the folder depends on your configuration, it can be just as $HOME/Mail, as $HOME/kde./share/apps/kmail/ or $HOME/.local/share/.local-mail (for new installations).

 

Äh … nein?!

Ändert man z. B. den Pfad von „Local Folders“ auf einen anderen, dann verschwinden die E-Mails. Soweit klar. Aber ändert man hinterher den Pfad wieder zurück auf ~/.local/share/local-mail, dann kommen sie nicht wieder – wie auch? Dort sind ja keine Daten!

----------

## mv

 *l3u wrote:*   

> Akonadi ist ja an sich eine super Idee

 

Es ist eine absolut besch... Idee: Ein Standard-Datenformat, das von tausenden Unix-Tools bearbeitet werden kann und menschenlesbar ist, wird durch ein quasi-proprietäres Binärformat ersetzt. Da haben ein paar Leute die Lektionen aus der Windows Registry-Datenbank-Fehlkonzeption nicht gelernt. Die Folgen - dass da jetzt im Prinzip nur noch kmail2 weiß, wo Deine Daten sind und wie darauf zugegriffen werden soll - siehst Du ja jetzt.  :Mr. Green: 

----------

## toralf

 *l3u wrote:*   

>  Nur funktionieren müsste es halt …

 Und hier setzt die (wohl eher bittere) Lektion an die KMail devs an - nämlich daß der grenzenlose Programmierspaß eben wirklich nur dann zu haben ist, wenn man die User und deren besondere Qualitätsansprüche an das Mailprogramm ignoriert.

----------

## firefly

 *mv wrote:*   

>  *l3u wrote:*   Akonadi ist ja an sich eine super Idee 
> 
> Es ist eine absolut besch... Idee: Ein Standard-Datenformat, das von tausenden Unix-Tools bearbeitet werden kann und menschenlesbar ist, wird durch ein quasi-proprietäres Binärformat ersetzt. Da haben ein paar Leute die Lektionen aus der Windows Registry-Datenbank-Fehlkonzeption nicht gelernt. Die Folgen - dass da jetzt im Prinzip nur noch kmail2 weiß, wo Deine Daten sind und wie darauf zugegriffen werden soll - siehst Du ja jetzt. 

 

Ach hör doch mit dem FUD auf. Akonadi bzw. die Datenbank da hinter speichert nicht die eigentlichen e-mails. Diese werden weiterhin in einem maildir gespeichert. akonadi dient nur als "generische" schnittstelle um auf PIM daten zugreifen zu können. Siehe auch

http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomuk-and-strigi-explained/

http://userbase.kde.org/Akonadi

http://blogs.kde.org/node/4503

Ich habe bei mir mal das ganze mit pop3 getestet, da ich nur imap verwende.

1. Über die Akonadi configuration eine pop3 ressource angelegt als zielort ein neues Verzeichnis innerhalb der "KMail Folders" Ressource als ziel angegeben.

2. In KMail2 ein check mail angestoßen

in KMail wurden die e-mails angezeigt. Und die e-mails befinden sich auch auf der festplatte unterhalb $HOME/.kde/share/apps/kmail/mail/ und zwar in dem verzeichnis .inbox

----------

## l3u

 *mv wrote:*   

> Es ist eine absolut besch... Idee: Ein Standard-Datenformat, das von tausenden Unix-Tools bearbeitet werden kann und menschenlesbar ist, wird durch ein quasi-proprietäres Binärformat ersetzt. Da haben ein paar Leute die Lektionen aus der Windows Registry-Datenbank-Fehlkonzeption nicht gelernt. Die Folgen - dass da jetzt im Prinzip nur noch kmail2 weiß, wo Deine Daten sind und wie darauf zugegriffen werden soll - siehst Du ja jetzt.

 

So weit ich das verstanden habe, agiert Akonadi lediglich als Cache, der auch ohne Probleme gelöscht werden kann, ohne Daten zu verlieren. Weil eben die Daten nach wie vor in allgemeingültiger und -verarbeitbarer Form gespeichert werden. Theoretisch.

 *firefly wrote:*   

> die e-mails befinden sich auch auf der festplatte unterhalb $HOME/.kde/share/apps/kmail/mail/ und zwar in dem verzeichnis .inbox

 

Das ist jetzt allerdings sehr interessant. Wenn ich mich aufraffen kann, versuch ich das ganze nochmal und schaue nach, ob die Mails wirklich dort sind ;-) Warum aber richtet man eine lokale Mail-Ressource namens ~/.local/share/local-mail ein, die als solche auch in KMail angezeigt wird – und dann werden die Daten doch woanders gespeichert?!

----------

## Josef.95

Zu dem Thema eventuell auch hilfreich und interessant --> http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade

----------

## firefly

 *l3u wrote:*   

>  *firefly wrote:*   die e-mails befinden sich auch auf der festplatte unterhalb $HOME/.kde/share/apps/kmail/mail/ und zwar in dem verzeichnis .inbox 
> 
> Das ist jetzt allerdings sehr interessant. Wenn ich mich aufraffen kann, versuch ich das ganze nochmal und schaue nach, ob die Mails wirklich dort sind  Warum aber richtet man eine lokale Mail-Ressource namens ~/.local/share/local-mail ein, die als solche auch in KMail angezeigt wird – und dann werden die Daten doch woanders gespeichert?!

 

ich habe bei mir 2 lokale maildir ressourcen einmal die "KMail Folders" und "Local Folders" und erstere zeigt auf das Verzeichnis welches ich angegeben habe. "Local Folders" zeigt bei mir auf "~/.local/share/local-mail"

Vermutlich wurde die "KMail Folders" vom migrator angelegt. Ich habe bei meinem Test halt ein Unterverzeichnis der "KMail Folders" Ressource als ziel für die pop3 ressource verwendet.

----------

## l3u

Okay, der Erfolg setzt teilweise ein, aber ich musste es erneut aufgeben. Angesehen davon, dass Akonadi immer mal wieder abgestürzt ist (oder zumindest irgend ein Prozess, der damit zu tun hat), ich X Mal KDE neugestartet hab, teilweise per /etc/init.d/xdm restart, etc., etc.:

Ich hab’s tatsächlich hinbekommen, KMail2 per Migrator meine alten Identitäten und Zugänge beizubringen. Ich hab’s auch (nach einigem Hin und Her) hinbekommen, ~/.local/share/local-mail als Standardordner für Mails einzurichten. KMail hat auch automatisch Ordner darin erzeugt (also „Posteingang“, „Mülleimer“, etc. – im Gegensatz zu KMail1 nicht als internationale Namen („inbox“, „trash“, etc.), sondern direkt so, wie sie heißen. Aber das ist mir eigentlich egal) und *tada* – speichert tatsächlich ankommende, gesendete, etc. Mails genau dort – in ~/.local/share/local-mail. Zusätzlich landen sicher irgendwelche Daten im Akonadi-Cache, aber ich weiß, wo die Mails sind.

So weit, so gut.

Dann hab ich per Akonadi meinen bisherigen KMail1-Mailordner ~/.kde4/share/apps/kmail/mail als „KMail-Mailordner“ als Ressource hinzugefügt. KMail zeigt die Ressource auch an und öffnet brav die ganzen Mails. Beim Versuch, die Daten in ein „normales“ Maildir umzuziehen (sei es „Lokale Ordner“ oder auch eine neue Ressource) hört der Spaß aber auf. Und zwar bei Ordnern mit Unterordnern:

Kopiere ich alte Daten aus der KMail-Mailordner-Ressource in einen Ordner auf der ersten Ebene einer Maildir-Ressource, schreibt Akonadi die Mails brav hinein. Kopiere ich aber eine Ordnerstruktur, wo ein Ordner noch Unterordner hat, werden diese zwar im Verzeichnis der Maildir-Ressource erstellt (per .Ordner.directory/Unterordner), aber die Mails, die ich kopiert habe, tauchen nirgends mehr auf. Sind aber interessanterweise per KMail zugänglich! Und hier bin ich wieder an dem Punkt, an dem ich war …

Kann es wirklich sein, dass Akonadi (noch) nicht richtig mit Unterordnern in Maildir-Ressourcen umgehen kann?! Hier ist z. B. eine Diskussion, wo jemand genau dieses Problem beschreibt – Ende 2010! http://forum.kde.org/viewtopic.php?f=20&t=92043

Scheinbar kann man eine neue KMail-Installation mit KMail2 mittlerweile „normal“ aufsetzen. Aber der Umzug von KMail 1 will einfach nicht ordentlich funktionieren … abgesehen davon, dass das Ganze einen ziemlich instabilen Eindruck macht – zumindest hier.

----------

## franzf

Ich denke mich zu erinnern, dass von dem "KMail-Maildir" abgeraten wurde, und stattdessen die normale maildir-ressource zu nehmen. Keine Ahnung ob das dein Problem behebt.

----------

## mv

 *firefly wrote:*   

>  *mv wrote:*    *l3u wrote:*   Akonadi ist ja an sich eine super Idee 
> 
> Es ist eine absolut besch... Idee: Ein Standard-Datenformat, das von tausenden Unix-Tools bearbeitet werden kann und menschenlesbar ist, wird durch ein quasi-proprietäres Binärformat ersetzt. Da haben ein paar Leute die Lektionen aus der Windows Registry-Datenbank-Fehlkonzeption nicht gelernt. Die Folgen - dass da jetzt im Prinzip nur noch kmail2 weiß, wo Deine Daten sind und wie darauf zugegriffen werden soll - siehst Du ja jetzt. :mrgreen: 
> 
> Ach hör doch mit dem FUD auf. Akonadi bzw. die Datenbank da hinter speichert nicht die eigentlichen e-mails. Diese werden weiterhin in einem maildir gespeichert.

 

Diese werden zusätzlich in einem maildir gespeichert - falls das funktioniert - aber es ist nur eine Frage der Zeit, bis das von KDE als obsolet erklärt wird. Man sieht eben Daten und hat die Kontrolle darüber verloren, wo sie herkommen. Noch schlimmer: Wo sie hingehen, also wer sie durch irgendwelche Bugs oder übersehenen Mechanismen abgreifen kann.

----------

## firefly

 *mv wrote:*   

> Diese werden zusätzlich in einem maildir gespeichert - falls das funktioniert - aber es ist nur eine Frage der Zeit, bis das von KDE als obsolet erklärt wird. Man sieht eben Daten und hat die Kontrolle darüber verloren, wo sie herkommen. Noch schlimmer: Wo sie hingehen, also wer sie durch irgendwelche Bugs oder übersehenen Mechanismen abgreifen kann.

 

und woher nimmst du die Sicherheit das es so kommen wird?

----------

## l3u

 *franzf wrote:*   

> Ich denke mich zu erinnern, dass von dem "KMail-Maildir" abgeraten wurde, und stattdessen die normale maildir-ressource zu nehmen. Keine Ahnung ob das dein Problem behebt.

 

Die KMail-Maildir-Ressource habe ich ja auch bloß als Kopierquelle verwendet. Die hat wohlgemerkt keine Probleme gemacht! Die Probleme sind erst aufgetreten, als ich versucht habe, den Inhalt in eine normale Maildir-Ressource zu kopieren!

 *mv wrote:*   

> Diese werden zusätzlich in einem maildir gespeichert - falls das funktioniert - aber es ist nur eine Frage der Zeit, bis das von KDE als obsolet erklärt wird.

 

So lang du das nicht belegst, ist das eine vollkommen haltlose Aussage. So weit ich weiß, hat niemand sowas vor. Wäre ja auch wenig sinnvoll!

----------

## mv

 *firefly wrote:*   

> und woher nimmst du die Sicherheit das es so kommen wird?

 

Das ist die erklärte Vision von KDE: Nepomuk als programmübergreifende Datenkrake zu etablieren. Kann man so ziemlich überall nachlesen, wo es um Nepomuk geht. Die Ausrede von Akonadi, dass die Speicherung in Nepomuk für die schnelle Suche nötig sei, zeigt, dass es dahin stark unterwegs ist. Hier mit der Doppelspeicherung der Daten aufzuhören ist offensichtlich inkonsequent - ein kurzzeitiges politisches oder technisches Zugeständnis. Klar wird (theoretisch) der Import oder Export in menschenlesbare Format möglich sein; so wie bei Windows der Import odre Export der Registry oder von Teilen davon als ASCII möglich ist.

----------

## franzf

Akonadi speichert die Mails nicht über Nepomuk, da wird nur getaggt (kann man jetzt mögen oder nicht), das macht der akonadi-nepomuk-feeder.

Akonadi speichert die Mails in einer normalen Datenbank (KDE-Default: mysql, Gentoo-Default: SQLite, gibt aber noch mehr Backends), damit nicht die ganzen Mails jedes Mal neu aus dem Maildir geladen werden müssen. Thunderbird cached AFAIK auch die Mails in ner DB.

Es wird zwar viel gemosert, dass mehrere Datenbanken gestartet werden, aber virtusoso ist halt keine Tabellenbasierte DB, wie es akonadi braucht, die Performance muss mies sein.

Sicher ist die ganze Technik noch nicht so bombig stabil, in kde-4.8.4 startet z.B. kmail nicht (kde-4.8.3 lief problemlos!), wenn nepomuk läuft (stürzt einfach ab), aber deine Kritik geht irgendwo voll daneben, das ist irgendwas zwischen Paranoia und Verschwörungstheorie...

----------

## Kampfkeks

Ich glaube auch nicht daran, dass diese "Doppelspeicherung" abgeschafft werden soll. Nicht im geringsten. Wenn, dann müssten ja auch die Mails eines imap-Accounts vom Server gelöscht werden, damit es nicht zu einer doppelten Speicherung auf dem Server und in der Akonadi-DB kommt. Der Vorteil von imap ist ja aber gerade der, dass alle Mails auf dem Server bleiben. Ich stelle mir diese Idee vor allem dann schlecht vor, wenn man z.B. zu Hause gerade einen Rechner mit Akonadi laufen hat, während man selbst unterwegs ist und auch gerne seine Mails mit seinem Smartphone abrufen möchte. Wenn der zu Hause laufende Akonadi einem da mit der Synchronisation zuvor kommt, kann man weder die alten noch die neuen Mails auf seinem Smartphone abrufen. Wenn man sich alleine das mal vor den Kopf hält, dann erkennt man schon wie unsinnig die Idee ist, dass irgendwann alles nur noch in Akonadi gespeichert werden soll. 

Die Migration meiner KMail-Accounts liegt schon eine weile zurück. Bei mir ging sie aber gut, da ich lokal keine Filter verwende. Ich habe die Filter auf den Accounts (imap) auf dem jeweiligen Server direkt eingestellt. Damit bekomme ich das ganze auch auf dem Smartphone gefiltert, und muss die Filter nicht doppelt und dreifach pflegen. Ansonsten läuft Akonadi und KMail recht gut. Ich kann jedenfalls ohne Probleme (Abstürze) meine tägliche Arbeit erledigen, sowohl im Büro als auch zu Hause.

----------

## mv

 *franzf wrote:*   

> Akonadi speichert die Mails nicht über Nepomuk, da wird nur getaggt (kann man jetzt mögen oder nicht), das macht der akonadi-nepomuk-feeder.

 

Wenn ich im gesamten Datenbestand auch mit mächtigen Suchfunktionen arbeiten kann, reicht taggen nicht. So zumindest verstehe ich diesen Text aus Deinem ersten Link:

 *Quote:*   

> Now, we didn’t want to code our own search support into Akonadi. It is quite a lot of work and difficult to get right. The virtual folders in KMail 1 are for example too slow to be useful for larger volumes of mail. What we did for searching instead was to use a technology that is actually good at finding stuff: Nepomuk.

 

Wenn Nepomuk so unabhängig wäre, wäre ja Benutzung von Akonadi mit USE="-semantic-desktop" kein Problem - man verliert halt nur ein paar Suchfunktionen. Offensichtlich wird das aber von Upstream bewusst nicht unterstützt.

 *Kampfkeks wrote:*   

> Wenn, dann müssten ja auch die Mails eines imap-Accounts vom Server gelöscht werden, damit es nicht zu einer doppelten Speicherung auf dem Server und in der Akonadi-DB kommt.

 

Es ging mir um die lokalen Daten (worüber ja diese Diskussion hier ging). Dass die Daten ungefragt vom Server gelöscht werden, hatte ich nicht gemeint. Das wird sicher nicht passieren. Was passieren kann (oder vielleicht sogar schon passiert ist), ist, dass auch die Serverdaten - sobald einmal gelesen - in Nepomuk zur Suche verbleiben und damit Datendieben potentiell zur Verfügung stehen. Das Problem dabei ist - und das ist das Grundproblem von Nepomuk, das ich kritisiere - dass man als Benutzer de facto keine Kontrolle über diese Daten hat, da diese nicht mehr menschenlesbar einsehbar sind: Für den Normalbenutzer bleibt ein undurchschaubarer Datenwust (auch wenn es vielleicht theoretisch Hilfsprogramme zu dessen Analyse gibt), und ein Einbrecher kann auf eine reichhaltige Datenbasis zurückgreifen...

----------

## firefly

 *mv wrote:*   

> Es ging mir um die lokalen Daten (worüber ja diese Diskussion hier ging). Dass die Daten ungefragt vom Server gelöscht werden, hatte ich nicht gemeint. Das wird sicher nicht passieren. Was passieren kann (oder vielleicht sogar schon passiert ist), ist, dass auch die Serverdaten - sobald einmal gelesen - in Nepomuk zur Suche verbleiben und damit Datendieben potentiell zur Verfügung stehen. Das Problem dabei ist - und das ist das Grundproblem von Nepomuk, das ich kritisiere - dass man als Benutzer de facto keine Kontrolle über diese Daten hat, da diese nicht mehr menschenlesbar einsehbar sind: Für den Normalbenutzer bleibt ein undurchschaubarer Datenwust (auch wenn es vielleicht theoretisch Hilfsprogramme zu dessen Analyse gibt), und ein Einbrecher kann auf eine reichhaltige Datenbasis zurückgreifen...

 

Deine ursprüngliche Aussage klang so als ob akonadi komplett für die Speicherung der e-mails und anderen PIM-Daten dient (und zwar in einer Datenbank). Nur das stimmt so nicht. Es ist richtig, dass Akonadi die PIM-Daten cached um einen schnelleren zugriff auf die Daten zu ermöglichen. Akonadi stellt in erster Hinsicht eine "standardisierte" Schnittstelle auf alle PIM Daten dar (z.b. e-mails oder Adressen).

Deine jetzige Aussage ist dagegen komplett ein anderes Thema. Und zwar geht es dir um die Gefahr die durch Caching jedweder Daten entstehen kann.

Bei jedem caching verfahren besteht die Gefahr, dass bereits gelöschte Daten sich noch im Cache befinden bis dieser aktualisiert wird. Ganz besonders groß ist diese gefahr, wenn man an der Schnittstelle vorbei (welche den Cache verwaltet) Daten verändert/löscht.

Es ist schade, dass in KMail2 nicht mehr die alte Variante (das direkte durchsuchen in den lokal Dateien im maildir/mbox Verzeichnis) der Suche funktioniert. Da hier einige raten auf Thunderbird zu wechseln. Dort wird schon länger für die Suche ein index aufgebaut. Und da existiert das gleiche Problem wie mv bei KMail2+akonadi+nepomuk anprangert.

----------

## l3u

Fernab der ganzen Grundsatzdiskussionen ist das Problem zunächst einmal, dass es einfach nicht richtig funktioniert …

----------

