dass mit den >600 GB eher d
Die freie Festplattenkapazität waren etwa 694GB, die 620GB sind ein Fantasieprodukt.
Mapenzi hat mehrfach von den 627MB der Inbox gesprochen und dann wahrscheinlich versehentlich daraus GB gemacht.
Die Anzahl der Mails ist dennoch sehr hoch und bedeutet das man ein Programm bräuchte um die E-Mails aus der mbox zu retten. Oder man sitzt halt sehr lange dran...
Klar sind auch 627 MB eine große Hausnummer. Doch man könnte relativ schnell eine Eingrenzung betreiben, in dem man die Datei sukzessive halbiert, viertelt, achtelt, ...
INBOX halbieren ... geht die eine Hälfte, geht die andere Hälfte? Weiter mit der defekten Hälfte. Die wieder halbieren usw.
Selbst bei hypothetisch 100 k Mails wäre man nach 15 Schritten auf überschlägig 3 Mails runter und könnte die problematische Stelle mit mMn vertretbarem Aufwand eingrenzen.
Ich weiß nicht, wie Mapenzis Script arbeitet. Angenommen, es zerlegt die INBOX in lauter einzelne eml-Dateien, könnte man die anschließend in einem Zug importieren. An der defekten Mail bleibt der Vorgang dabei möglicherweise hängen, aber dann hätte man die auch identifiziert.
Vielleicht wäre auch ImportExport Tools NG einen Versuch wert. Direkt den Posteingang mal als eml-Dateien rausschreiben. Mit 'Reparieren' wurde es ja bereits versucht, aber das Ergebnis war nicht nachhaltig. Eventuell bewirkt ein Export noch etwas mehr. Filtert die defekte Mail weg oder repariert implizit.
Es gäbe also durchaus noch Mittel und Wege.
Gruß,
Sehvornix
Mapenzi hat mehrfach von den 627MB der Inbox gesprochen und dann wahrscheinlich versehentlich daraus GB gemacht.
Danke für deinen Hinweis 
Das war natürlich ein Tippfehler. Ich werde ihn sofort korrigieren.
Ich weiß nicht, wie Mapenzis Script arbeitet.
Es ist kein Script im Sinne wie du es verstehst, sondern eine einfache Kommandozeile, auszuführen in der "Terminal" App von macOS.
Die Kommandozeile lautet
split -b 10000k ~/Library/Jackie Testd. h.die Mailbox-Datei 'Jackie' , die ich in meine User-Library kopiert habe, soll in mehrere kleinere Mbox-Dateien "Test" von jeweils 10 MB aufgeteilt werden. Und die resultierenden kleinen Mbox-Dateien sollen in meinem "Home" Ordner gespeichert werden; Da die Datei Jackie 78 MB groß ist, werden sieben Dateien à 10 MB erstellt, und eine achte mit 8 MB:
Da die meisten Mac-User sich vor dem Terminal fürchten, würden sie in einem solchen Fall eher das kleine "Mbox Breaker" Tool gegen einen geringen Aufpreis herunter laden, der das gleiche ebenso fix leisten kann.
Auch für Windows gibt es mehrere solcher "Splitting" Tools zu entsprechenden Preisen. Die freien Versionen können allerdings nicht mal eine 1 GB große Mbox-Datei stemmen.
Hab mal ein bisschen gebastelt und ein einfaches Python-Script erstellt, was eine mbox-Datei 'Inbox' in einzelne .eml-Dateien zerlegt.
Inspiriert von hier: https://stackoverflow.com/questions/1271…ur-within-lines
Ich bin kein Programmierer. Das gesagt, ist das Ergebnis Quick & Dirty, ohne Fehlerbehandlung, ohne speziellen Komfort und mit ein paar nicht abgeprüften Annahmen:
#!/usr/bin/env python3
#
# Muster mit Shebang für alle Systeme
def files():
n = 0
while True:
n += 1
yield open('%d.eml' % n, 'w')
def main():
pat = 'From - '
fs = files()
outfile = next(fs)
once = 1
with open('Inbox') as infile:
for line in infile:
if pat in line:
if once == 1:
outfile.write(line)
once = 0
else:
outfile = next(fs)
outfile.write(line)
else:
outfile.write(line)
if __name__ == "__main__":
main()Für eine mbox-Datei mit ca. 4k Mails braucht das Script auf meinem PC ca. 20 Sekunden. Für 100k Mails würde es ungefähr 8 Minuten benötigen.
Dafür braucht man halt dann Python, packt die Pythondatei und die Inbox-Datei in dasselbe Verzeichnis, startet das Script und hat die Inbox-Datei in X eml-Dateien zerlegt im selben Verzeichnis. Heißt die mbox-Datein nicht 'Inbox', dann muss man halt das Script an der betreffenden Stelle ändern und den konkreten mbox-Dateinamen eintragen.
Natürlich kann man dasselbe auch mit ImportExportTools NG anstellen. Aber hier ging es ja um einen Lösungsansatz für eine mutmaßlich defekte Inbox-Datei. Das Script zerlegt die mbox-Datei einfach nur an der Stelle 'From - ' ohne jegliche weitere Prüfung. Ob die entstandene .eml-Datei intakt ist, würde man im Einzelfall erst beim Doppelklick oder beim Massenimport sehen.
Gruß,
Sehvornix
Das über einen Split-Befehl zu lösen, ist nicht optimal, weil er die mbox nach einer fixen Größe trennt. Dabei wird nahezu immer die jeweils letzte E-Mail im Block in zwei Teile zerrissen. Das möchte man gewiss nicht. Besser wäre es daher, nicht nach der Dateigröße zu trennen, sondern nach einer bestimmten Anzahl von E-Mails.
Unter Linux und vermutlich auch beim Mac lässt sich das besser mit dem Befehl awk lösen. Innerhalb einer mbox beginnen E-Mails mit "From". Darauf lässt sich filtern.
awk -v n=100 ' /^From / { if (m++ % n == 0) f=sprintf("part_%04d", int(m/n)+1) } { print >> f } name_der_ Input-DateiIch denke, der Befehl ist selbsterklärend. Es werden einzelnen Dateien mit dem Namen "part"+vierstellige Nummer erzeugt. Getrennt wird in dem Beispiel nach 100 E-Mails.
Vielen Dank ggbsde . Dein freut mich. Allerdings ist mir eben beim Lesen des Scripts von Sehvornix eine Unzulänglichkeit aufgefallen, der beide Lösungen unterliegen.
Mein awk-Beispiel trennt anhand des Schlüsselwortes "From ". Hat man Mails in der mbox, die dieses Schlüsselwort im Text enthalten, beispielsweise einen Satz, der mit "From " beginnt, zählt der awk dies als den Beginn einer neuen Mail. Ähnliches gilt für das Script von Sehvornix.
Der awk ist für diesen Fall etwas robuster, weil er zunächst nur zählt und nicht gleich trennt. Im Beispiel wird erst nach n=100 Froms getrennt.
Wurde zwischendurch aus Versehen hochgezählt, dann enthält die so generierte Datei weniger als 100 Mails. Das ist nicht weiter schlimm. Sollte das aber zufällig genau beim hundertsten der Fall sein, dann wird diese Mail zerrissen. Erhöht man den Wert von n verringert sich das Risiko entsprechend.
Da ich ich wegen der Benutzung von Maildir keine mbox zur Verfügung hatte, habe ich mit mboxen aus diesem Apache Archiv getestet: https://lists.apache.org/list?dev@perl.apache.org:2000-9
Obwohl die Mails dort in Englisch verfasst sind, das "From " demnach häufiger auftritt, ist mir bei meinen Tests kein solcher Fehler aufgefallen.
Übrigens beginnen diese Mails stets mit einem "From " und nicht mit einem "From - ".
Insgesamt ist diese einfache Lösung über das awk-Kommando damit immer noch wesentlich sicherer als ein split. Der Split zerstört nahezu immer eine Mail pro Teil, der awk nur in seltenen Ausnahmefällen.
Übrigens beginnen diese Mails stets mit einem "From " und nicht mit einem "From - ".
In meinem Thunderbird ist das durchgängig der Fall. Woher hast Du die Info, dass es nicht grundsätzlich gilt?
Davon ab ist aber natürlich auch nicht ausgeschlossen, dass 'From - ', also mit Leerstelle vor und hinter "-" irgendwo im Text vorkommt.
Gruß,
Sehvornix
Danke für die Referenz.
Fakt ist aber auch:
Offenbar lässt die RFC-4155 einen gewissen Spielraum:
Der Bindestrich ist schon eine ganze Weile da. Beiträge, die sich um den Übergang jeweils zur nächsten Mail drehen, beschreiben den Bindestrich hier im Forum auch schon eine ganze Weile immer wieder.
Gruß,
Sehvornix
Mails in TB beginnen immer mit "From - " und ggf. mit einer Zeitangabe dahinter. Aber immer am Beginn einer Zeile Beginnt in der eigentlichen Nachricht eine Zeile mit "From" so fügt TB ein Leerzeichen davor ein (gerade nochmal getestet).
Das awk Script ist also korrekt.
Woher hast Du die Info, dass es nicht grundsätzlich gilt?
Schrieb ich oben. Aus mboxen, die ich mir zum Testen aus dem Apache-Archiv geholt habe. Die entsprechen deinem Screenshot, der wohl aus dem RFC stammt.
