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