Fwd: Re: KMail-Datenübernahme! ... verwendet nur alten Datenbestand

Hallo Thomas, danke für den Tip. Der Tip mit den KDE-Ressourcen und der akonadi-ressource hat mich vielleicht einen Schritt weitergebracht. Dort konnte ich nur den Verweis "/home/re/.kde4/share/apps/kabc/std.vcf" auf die alte Adressdatei finden und fügte die akonadi-ressource hinzu. Der Ort der Adressen, die vom Adressbuch gepflegt werden, bleibt in der KDE-Ressourcen- Verwaltung jedoch leider geheim. Jetzt gehe ich folgende Schritte: a) Ausdenken eines bestimmten Strings, der garantiert noch in keiner Datei auf dem Rechner vorkommt. b) Mit Adressbuch eine neuen Kontaktadresse hinzufügen, wobei der vorgenannte String sowohl im Personennamen als auch in der EMailadresse vorkommt. Außerdem testweise ein Änderung eines bestehenden Kontaktes vornehmen. c) Zum Versenden einer EMail die neu angelegte Adresse vom neu gestarteten KMAIL vorschlagen lassen. FEHLANZEIGE! KMAIL kennt sowohl die Adresse als auch die testweise Kontaktänderung immer noch nicht! d) Suchen des Strings in allen Dateien auf dem Rechner. Ergebnis der Suche: 108 Dateien gefunden. 103 Dataien davon in irgendwelchen Unterverzeichnissen von /proc (vielleicht nicht von Bedeutung). Die restlichen 5 Dateien sind: 1) /home/re/.kde4/share/apps/korganizer/freebusyurls Hier befinden sich nur ein paar kürzlich mit "Adressbuch" erzeugte EMail- Adressen in der Form "[A5CKZ1BR4_@A5CKZ1BR4.de] url= " sonst gar nichts. Selbst Löschungen von Kontakten mit "Adressbuch" lassen hier keinen Eintrag verschwinden! 2) /home/re/.local/share/akonadi/db_data/ib_logfile0 Sie scheint keine reine Textdatei zu sein. KWrite findet aber meinen String im Block BEGIN:VCARD EMAIL:A5CKZ1BR4_@A5CKZ1BR4.de FN:_A5CKZ1BR4 N:_A5CKZ1BR4;;;; NAME:_A5CKZ1BR4 UID:X13IYNrMb0 VERSION:3.0 END:VCARD Merkwürdigerweise sind dort die Kontaktinformationen sowohl in alter als auch(!) der neuen Version vorhanden. 3) .local/share/akonadi/db_data/mysql-bin.000660 Auch dies ist vermutlich keine reine Textdatei und KWrite findet meinen String in einem Block, der nicht so textförmig aussieht wie in der vorstehenden Datei. Daten anderer Kontakte konnte ich hier nicht finden. 4) .local/share/akonadi/db_data/akonadi/parttable.ibd Hier gilt der gleiche Kommentar wie für die obige Datei unter Punkt 2) 5) .kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano- virtuoso.db Dies ist keine reine Textdatei aber ein ziemliches Chaos verschiedenster Informationen. Je länger ich ins Innere von Linux schaue, desto undurchsichtiger wird es. Eine Problemlösung kann ich noch immer nicht erkennen. Wo gibt es professionelle Hilfe?? Mit freundlichen Grüßen Reinhold

Am Freitag, 25. November 2011, 17:40:59 schrieb R_Schilling: Hallo Reinhold,
Der Tip mit den KDE-Ressourcen und der akonadi-ressource hat mich vielleicht einen Schritt weitergebracht. Dort konnte ich nur den Verweis "/home/re/.kde4/share/apps/kabc/std.vcf" auf die alte Adressdatei finden und fügte die akonadi-ressource hinzu. Der Ort der Adressen, die vom Adressbuch gepflegt werden, bleibt in der KDE-Ressourcen- Verwaltung jedoch leider geheim.
Bitte schliesse mal kmail (wirklich schliessen und nicht nur das Fenster ausknipsen! Jetzt startetst Du 'kontact', gehst links im Menu auf "Kontakte" und im Feld "Adressbücher" sagst Du per rechter Maustaste "Adressbuch hinzufügen" Nun wählst Du KDE-Adressbuch (traditional) und wählst Dein altes Adressbuch. "~./kde4/share/apps/kabc/std.vcf" (Standard) So habe ich alle Adressbücher zurückgeholt. Ich habe hier dienstlich und privat strikt getrennt und daher nicht nur ein File. MfG Th. Moritz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo Reinhold, hallo Leute, Am Freitag, 25. November 2011 schrieb R_Schilling:
Die restlichen 5 Dateien sind:
1) /home/re/.kde4/share/apps/korganizer/freebusyurls
Die Datei sagt mir nicht wirklich etwas, sieht aber harmlos aus. Akonadi verwendet MySQL zur Datenspeicherung. Die Dateien unter 2), 3) und 4) werden von MySQL verwaltet:
2) /home/re/.local/share/akonadi/db_data/ib_logfile0
Merkwürdigerweise sind dort die Kontaktinformationen sowohl in alter als auch(!) der neuen Version vorhanden.
Das ist gar nicht merkwürdig. Diese Datei loggt und puffert alle Schreibzugriffe auf die Datenbank (zumindest für die InnoDB-Engine), bevor sie in der "richtigen" Datei (siehe "4)") eingetragen werden. Das erspart MySQL einen Haufen random writes. Bei Datenbanken mit vielen Änderungen bringt das performancemäßig einiges und verhindert, dass die Festplatten zu sehr glühen ;-) In dieser Datei wird auch der alte Eintrag gepuffert, um bei einem Abbruch der Änderung ein Rollback machen zu können. (Oder er ist zufällig noch vom ursprünglichen Erstellen des Eintrags vorhanden.)
3) .local/share/akonadi/db_data/mysql-bin.000660
Das könnte (!) ein MySQL Binlog sein (geraten anhand des Namens).
4) .local/share/akonadi/db_data/akonadi/parttable.ibd
Das ist die eigentliche Datenbank-Datei.
5) .kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano- virtuoso.db Dies ist keine reine Textdatei aber ein ziemliches Chaos verschiedenster Informationen.
Anhand des Pfades würde ich mal vermuten, dass das der Index von Nepomuk (Suchfunktion) ist.
Je länger ich ins Innere von Linux schaue, desto undurchsichtiger wird es.
Ich hoffe, obiges hat etwas Nebel beseitigt ;-) Gruß Christian Boltz -- Die Frage des besten MUA hat bei mir längst die Vernunftebene verlassen. Dann wäre ich bei Evolution geblieben. Ich will diese verfluchte Kiste in die Knie zwingen, Punkt. Koste es, was es wolle. Also mutt. Den Feind auf seinem eigenen Territorium besiegen. [Ratti] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Christian Boltz
-
R_Schilling
-
Thomas Moritz