Adressbuch leer trotz ansonsten erfolgreichem Import des alten Profil-Ordners

Gibt es außer der Datei abook(2).sqlite noch eine Datei abook.sqlite? Wenn Ja, benenne letztere mal um in abookalt.sqlite,

Benenne dann die abook(2).sqlite um in abook.sqlite.

Starte TB neu und prüfe ob die Adressen jetzt da sind.

Eine Sicherung des Profils ist auf alle Fälle anzuraten (normalerweise braucht es keine Sicherung, aber Vorsicht ist die Mutter der Porzellankiste).

Zitat von Road-Runner

benenne letztere mal um in abookalt.sqlite,

Diese umbenannte Datei abookalt.sqlite kannst Du dann löschen.

Zitat von Annie56

Können Sie sich das erklären?

Nein, kann ich nicht. Ich habe auch noch nie erlebt dass Einträge doppelt und dreifach vorhanden waren.

Zitat von Annie56

Und: haben Sie eine Idee, wie ich diese Doppelt- bzw. Dreifacheinträge mit einem "Federstreich" weg bekomme?

STRG-Taste gedrückt halten, die zu entfernenden Einträge per Linksklick markieren. Anschließend löschen. Eine andere Methode ist mir nicht bekannt.

Zitat

der Kalender und die Aufgaben sind auch leer

Handelt es sich hier um den in TB integrierten Kalender oder einen Google-Kalender?

Ich würde Folgendes tun:

1. den ganzen Profilordner sichern (ich bin darin etwas pingelig, bei mir läuft nichts ohne Sicherung)

2. Die Datei local.sqlite (vom 16.03.2021) umbenennen in localalt.sqlite

3. die Datei local (3).sqlite (vom 13.03.2021) umbenennen in local.sqlite

dann TB neu starten und prüfen ob die Daten wieder da sind.

Ich bin mir jetzt nicht sicher, denke aber dass die Aufgaben auch in der Datei local(3) .sqlite (vom 13.03.2021) gespeichert sind. Nach dem Umbenenne und dem Neustart sollten die Aufgaben dann auch wieder da sein.

Hallo Annie,

Deine Frage ist als erledigt markiert. Setz das mal auf unerledigt, sonst liest ein Teil der Helfer darüber hinweg und wundert sich auch nicht, warum immer neue Beiträge nachgereicht werden.

Hallo @B. Mueller ,

Zitat von B. Mueller

Das ist die korrekte Größe.

Die «prefs*.js» Dateien haben übrigens nichts mit dem Kalender zu tun, sie enthalten die Konfiguration deines TB.

Das ist die Größe einer leeren oder nahezu leeren local.sqlite.

Der zweite Punkt ist ziemlich sicher in diesem Fall nicht richtig. In der prefs.js wird die cal_id vermerkt. Leider kann man die local.sqlite nicht einfach so in ein anderes Profil kopieren, ohne herauszubekommen, welche cal_id in dem Kalender genutzt wird und diese dann an entsprechender(n) Stelle(n) in der prefs.js editieren. Oder andersrum in der local.sqlite auf die neue gültige cal_id umändern, was dann aber SQL-Kenntnisse erfordert.

tom996 hat dazu ein paar interessante Anmerkungen gemacht: cal_id

und Susi to visit hat an anderer Stelle auch schon mal schön beschrieben, wie man so eine local.sqlite in ein neues Profil migriert. Finde den Beitrag aber just nicht.

Annie56 , die prefs*.js nacheinander an Position 1 zu stellen und mit den unterschiedlichen local.sqlite zu kombinieren, kann vielleicht auch noch zum Ziel führen. Es hängt dann aber sehr davon ab, wie Du die Migration gemacht hast, ob da überhaupt noch eine passende Kombination dabei ist. Außerdem sind die prefs*.js nicht einfach so entstanden, sondern weil Thunderbird wiederholt die Konfiguration nicht verarbeiten konnte und sich dann stattdessen eine neue prefs.js generiert hat.

Um aus der local.sqlite die cal_id auslesen und überhaupt mal schauen zu können, welche local.sqlite denn die richtige ist, benötigst Du ein Tool, um diese Dateien öffnen zu können. Tipps findest Du auch in dem oben schon verlinkten Beitrag.

Zitat von Annie56

local.sqlite-shm (vom 21.03.2021)

local.sqlite-wal (vom 21.03.2021)

Das sind temporäre Dateien zur Laufzeit von Thunderbird. Wenn Du einen Kopiervorgang vorgenommen hast, während diese Dateien zu sehen sind, war das mindestens unglücklich. Es wurde ja schon geschrieben aber lieber einmal mehr wiederholt: bei jeglichen Kopier- und Verschiebeaktionen *muss* Thunderbird geschlossen sein.

Gruß

Sehvornix

Zitat von Sehvornix

Der zweite Punkt ist ziemlich sicher in diesem Fall nicht richtig. In der prefs.js wird die cal_id vermerkt.

Stimmt genau. Es gibt Einträge in der prefs.js, die für die Kalender maßgeblich sind. Ohne die korrekte ID funktioniert es nicht.

Zitat von Sehvornix

und Susi to visit hat an anderer Stelle auch schon mal schön beschrieben, wie man so eine local.sqlite in ein neues Profil migriert. Finde den Beitrag aber just nicht.

Der Beitrag findet sich hier. Den hat Annie56 anscheinend bereits gefunden.

Zitat von Sehvornix

Es hängt dann aber sehr davon ab, wie Du die Migration gemacht hast,

Ich würde in diesem Fall deshalb auch zunächst nicht an der prefs.js editieren. Bei Übernahme eines kompletten, unbeschädigten Profils, wird die prefs.js ebenfalls übernommen. Die IDs müssten daher passen. Hier ist offensichtlich etwas anderes schiefgegangen. Vermutlich genau das, was auch für die neuen prefs*.js verantwortlich war, was immer das auch war.

Wenn das originale Profil noch vorhanden und intakt ist, müsste das Kopieren des kompletten Ordner Thunderbird aus Roaming auch sämtliche Kalender übernehmen, ohne dass weitere Aktionen notwendig wären.

Sollte schon das alte Profil einen Knacks haben, aber immerhin die Kalender noch funktionieren, bliebe immer noch die Möglichkeit, die Kalender zu ex- und dann in ein ganz neues Profil zu importieren.

Tool: zum Beispiel DB Browser for SQLite von hier.

Zitat von Annie56

Der Kalender auf meinem alten Rechner sah anders aus, vielleicht lässt sich der alte einfach nicht in eine augenscheinlich neue Version des Kalenders integrieren.

Welches war denn die vorherige Version von Thunderbird? Also zumindest in der 68.x Linie gibt es die local.sqlite auch schon.

Zitat von Annie56

eine local.sqlite-Datei (aus dem Jahr 2014) enthält

Die würde ich an Deiner Stelle ignorieren. Die Datei local.sqlite bekommt immer das laufende Datum, jedes Mal, wenn Thunderbird gestartet wird. Eine Datei mit einem Datum von 2014 ist seit 7 Jahren nicht mehr angesprochen worden.

Zitat von Annie56

Ist es denn normal, dass es zwei Ordner "Calender-Data" gibt und zwei local.sqlite-Dateien?

Nein. Selbst wenn mehrere Kalender angelegt werden, landen die alle in der einen local.sqlite, nur mit unterschiedlichen cal_id.

Zitat von Annie56

Oder sollte ich besser die Finger davon lassen?

Das liegt natürlich in Deinem Ermessen und Einschätzung Deiner Fähigkeiten. Aber solange Du mit Kopien der fraglichen Dateien arbeitest und ein Backup von Deinem Thunderbird-Profil vorhälst, ist das Risiko meiner Meinung nach recht gering. Es hält Dich jedenfalls nichts davon ab, die diversen local.sqlite bei geschlossenem Thunderbird mal aus dem calendar-data-Verzeichnis zu kopieren und an anderer Stelle abzulegen sowie diese dann mit dem genannten Tool zu öffnen und Dich darin umzuschauen.

Ebenso kannst Du entsprechend dem Link auf den Beitrag von tom996 sehen, wo in der prefs.js die cal_id steht, die Du mit den Datenbankinhalten vergleichen kannst. Wenn die nicht identisch sind, kann Thunderbird gemäß prefs.js die Datensätze in der local.sqlite nicht zur Anzeige bringen.

Gruß

Sehvornix

Wollt ihr euch das wirklich antun? Ich würde auch dem alten Profil schon allein wegen der pref* und dem doppelten calendar-data nicht mehr völlig trauen. Dass das Kopieren nicht zum Erfolg führt, zeigt m.E. ebenfalls, dass da etwas nicht stimmt.

Ich würde die Kalender und Kontakte exportieren, dann ein neues Profil erstellen und sie dort importieren. Die IMAP-Konten sind schnell neu eingerichtet und die Lokalen Ordner lassen sich rasch kopieren. Dann wäre alles sauber.

Zitat von Annie56

als kommabasierte Datei mit dem eingebauten Export-tool von TB?

ich würde das standardmäßig vorgeschlagene vCard-Format nehmen.

Zitat von Annie56

sowie den Kalender als local.sqlite-Dateien in verschiedenen Versionen.

Dann hast du wieder die Misere mit den IDs. Weshalb willst du unbedingt an den splite festhalten anstatt die Kalender auch zu exportieren?

Zitat von Annie56

Wie lassen sich denn die lokalen Ordner kopieren?

Die befinden sich unter /mail/local folders

Zitat von Annie56

deinstalliere TB und neuinstalliere es anschließend.

Das ist nicht nötig.

Hallo Susanne,

Zitat von Susi to visit

Wollt ihr euch das wirklich antun?

Nein, muss nicht sein, wenn es eine andere Lösung auch tut Die Arbeit liegt eh bei der Fragestellerin.

Ich würde auch dem alten Profil schon allein wegen der pref* und dem doppelten calendar-data nicht mehr völlig trauen. Dass das Kopieren nicht zum Erfolg führt, zeigt m.E. ebenfalls, dass da etwas nicht stimmt.

Ich würde die Kalender und Kontakte exportieren, dann ein neues Profil erstellen und sie dort importieren. Die IMAP-Konten sind schnell neu eingerichtet und die Lokalen Ordner lassen sich rasch kopieren. Dann wäre alles sauber.

Im Prinzip bin ich da bei Dir, aber wie soll Annie an die Kalenderdaten rankommen (für den Export)? War es nicht so, dass da vorher schon ein Umzug nicht so ganz geklappt hat und somit das alte Profil auch nicht richtig zu reaktivieren war? Ich kann aus der Beschreibung auch nicht klar nachvollziehen, ob es noch ein unverändertes Profil gibt. Und so kommt es möglicherweise an den Punkt, dass es gar nicht mehr anders geht, als die jüngste local.sqlite mit den echten Daten irgendwie noch mal zugänglich zu machen.

Hallo B. Mueller,

Zitat von B. Mueller

Hmm - hier wird beim Start von TB eine leere Datei «local.sqlite-wal» mit dem aktuellen Datum erzeugt. Wird der Kalender nicht verändert, wird sie beim Beenden von TB wieder gelöscht. Die «local.sqlite» bleibt dabei unangetastet.

Das Dateidatum ist nur dann unverändert, wenn man den Kalender nicht nutzt (das Kalendertab anzeigen ist in dem Sinne keine Nutzung). Davon ist bei der Fragestellerin wohl nicht auszugehen . Sobald Aktivitäten im Kalender stattfinden, bekommt die Datenbankdatei das aktuelle Nutzungsdatum. Das passiert bereits automatisch für Wiedervorlagen, aber auch für Erinnerungen, für erledigte Aufgaben und natürlich sowieso, wenn ein Eintrag geändert oder neu erstellt wird.

Gruß

Sehvornix