IMAP Ordner belegt 146 GB

Rechtsklick auf den Ordner --> Komprimieren

Hallo,

Quote from blueice_haller

Thunderbird, Rechtsklick auf den Ordner Jugend, Eigenschaften

Tab Allgemein: Größe auf Datenträger: 41,5 MB.

Wie ist das mit den 146 GB in diesem Satz in Einklang zu bringen?

Quote from blueice_haller

ich habe bei einem IMAP Postfach das Problem, dass eine Datei 146GB belegt:

Quote from blueice_haller

Würde es funktionieren,

Prinzipiell ja, aber die Datei wird dadurch nicht kleiner.

Such mal in deinem Profil Ordner im Dateisystem nach Dateien 'nstmp...'. Die sind oft sehr groß und können gelöscht werden

Hallo,

die Datei 'Jugend' ist in Thunderbird ein entsprechend benannter Unterordner 'Jugend' im Posteingang. Prüfe und teile mal mit, wie viele Mails in diesem Ordner abgelegt sind.

Weiter, blende Dir mal die Spalte 'Größe' mit ein und sortieren in dem Unterordner nach Größe der Mails. Da finden sich dann am Anfang oder am Ende die größten Mails (mit mutmaßlich Anhängen), ähnlich, wie Du das jetzt mit Dateien gemacht hast. Das sollte Dir Aufschluss geben, woher das Volumen resultiert.

Oder es sind wirklich so dermaßen viele Mails, dass ein solches Volumen zustande kommt. Bei 153 GB stelle ich mir allerdings eine Fantastillion Mails vor, um in Summe auf derartige Größenordnungen zu kommen.

Gruß
Sehvornix

Edit: die nstmp* Dateien können gelöscht werden. Hilfsweise erst woandershin auslagern und nach Vergewisserung von ausbleibenden Nebenwirkungen, dann löschen. Sind aber ja nur ein Tropfen auf den heißen Stein ..

Komprimieren von dem Unterordner 'Jugend' hattest Du ja bereits erfolglos probiert.

Wie wäre folgende Idee: Thunderbird beenden, dann die Datei Jugend aus dem Thunderbird-Profil an eine andere Stelle verschieben, anschließend Thunderbird wieder starten. Thunderbird wird sich mit dem Server synchronisieren (IMAP) und den Unterordner 'Jugend' neu vom Server her erstellen. Ggf. über 'Abonnieren' nachhelfen, dass der Ordner wieder abonniert wird, falls das nicht automatisch geschieht. Spannend wird sein, ob der Unterordner die zu erwartende Größe bekommt oder wieder über alle Grenzen wächst.

Sofern die Festplattenkapazität ausreicht, könnte man später die ausgelagerte Datei Jugend auch noch mal unter

C:\Users\<Username>\AppData\Roaming\Thunderbird\Profiles\....default\Mail\Local Folders

einfügen. Damit taucht der Unterordner 'Jugend' in Thunderbird unter 'Lokale Ordner' auf und kann dort weiter inspiziert werden.

Gruß
Sehvornix

Ich stimme Sehvornix zu. Die nstemp Dateien sind relativ neu, das lässt vermuten, das das komprimieren des Ordners fehlgeschlagen ist. Genau dann bleiben nämlich diese nstmp Dateien zurück. Da hilft dann sein. Vorschlag (bei IMAP Konten).

Quote from ggbsde

das lässt vermuten, das das komprimieren des Ordners fehlgeschlagen ist. Genau dann bleiben nämlich diese nstmp Dateien zurück.

Hattest du nicht vor kurzem erklärt, dass in der Version 128 beim Komprimieren keine nstmp Dateien mehr erstellt werden.

Quote from ggbsde

nstmp Dateien sind Überbleibsel fehlgeschlagener Reparaturen oder Komprimierungen von Ordnern. TB128 verwendet und erstellt diese Dateien nicht mehr.

RE: TB nimmt übermäßig viel Speicherplatz in Anspruch

Oha, erwischt. Da muß ich wohl nochmal genauer recherchieren.

Quote from ggbsde

Da muß ich wohl nochmal genauer recherchieren.

Der Code der Komprimierungs-Funktion ist für die Version 128 umgeschrieben worden in Bug 1890448 "Rewrite folder compaction"

Mit dem Erfolg, dass das Komprimieren in der v128 wesentlich länger dauert als in der v115.
Siehe Bug 1904208 "Investigate performance impact of FlushFileBuffers()", in dem die Geschwindigkeiten der Komprimierungsvorgänge mit dem alten Code (v115) und dem neuen Code (v128) verglichen werden.

Bisher hieß es doch im Zusammenhang dieser 128er-Probleme, dass fehlgeschlagene Komprimierungen diese großen temporären Dateien hinterlassen würden. nstmp oder das neuere Format.

An anderer Stelle wird beschrieben, wie in 128 die mbox-Dateien beim Komprimieren kurrumpieren, was man bei IMAP insofern korrigieren kann, als das korrekte Inhalte vom Server her wiederhergestellt werden können.

Hier, wenn es sich denn am Ende belegen lässt, zeigt sich, dass mbox-Dateien über alle Grenzen wuchern können, obwohl der eigentliche Inhalt nur einen Bruchteil belegen würde (41.5 MB zu unglaublichen 146 GB laut OP). Zudem funktioniert die Komprimierung für die 146 GB-Datei nicht.

Erst kürzlich hatten wir hier einen Thread, wo es um tatsächlich so große mbox-Dateien ging, aber dort klappte die Synchronisierung mit dem Server mutmaßlich wg. Timeout nicht mehr. Auch in dem Szenario wurde die Festplatte zugemüllt.

Persönlich bin ich zwar nicht betroffen. Habe die Updates blockiert und bin bisher produktiv bei 115 geblieben. Fazit bisher: mehr als berechtigt! Den unfreiwilligen 128esr-Betatestern wird jedenfalls arg viel zugemutet bis hin zu Datenverlust.

Interessant auch, was in dem Bugreport nachzulesen ist. Da kommen so Symptombekämpfungsvorschläge, wie, einfach alle nstmp* zu löschen, falls welche da sein sollten. Immerhin hält noch ein Entwickler ein Stopp dazwischen, weil es ja durchaus auch zufällig reale Ordner Namens nstmp* geben könnte. Da sollte man den Nutzern vielleicht nicht einfach die Daten löschen ..

Gruß
Sehvornix

Quote from blueice_haller

Jetzt stehen die 146 GB wieder zur Verfügung.

Waren die 146 GB nicht das Problem??

Quote from blueice_haller

das Problem, dass eine Datei 146GB belegt: