Wie kann ich eine defekte Datei wiederherstellen?

[DrMartinus]

Ich habe die letzten Tage an einer Datei gearbeitet, in der viele Informationen enthalten sind, die ich mühsam aktualisiert habe. Die automatischen Backups und Zwischenstandsspeicherung funktionierte erst ohne Probleme, aber zuletzt blieb LO bei einer solchen Zwischenstandsspeicherung stecken. Nach langem Warten (30 Minuten ca., sonst dauerte das Speichern um die 10 Sekunden) habe ich mich schließlich entschlossen, LO zu schließen, da es auch sonst auf Eingaben nicht reagierte. Beim Neustart bot es die Wiederherstellung an, wie üblich, dann aber fiel dieses Dokument raus. Es wurde die zuletzt gespeicherte Version wieder geladen, die die Arbeit von ca. 15 Stunden nicht enthält. Na gut, ich habe die Datei dann unter einem anderen Namen gespeichert. Dann habe ich im Backup-Ordner versucht, die Datei zu finden, dort war aber nur ein Backup mit 0 B Größe zu finden. Dankenswerterweise hatte LO aber die beschädigte Datei im letzten Status separat abgespeichert, so dass ich versuchte, diese zu öffnen. Doch da bleibt LO in der Mitte stecken und rührt sich nicht mehr. Es geht nur ein "Kill", um LO zu beenden. Mir fiel auf, dass die Datei über 50 MB groß ist - sie enthält keine Bilder, und zuvor war sie so etwas um 230 kB groß. Sie ist also aus irgendeinem Grund maßlos aufgebläht.
Hat irgendjemand eine Idee, was man da machen kann? Ich habe mal die Datei mittels Ark entpackt und die Datei content.xml näher angeschaut, es scheint, dass alle Daten enthalten sind. Weil die Datei alle Infos in einer Zeile gespeichert hat, d.h. ohne Zeilenumbrüche, ist es schwer, zu erkennen, ob da irgendwo ein Fehler drin ist.
Hat hier jemand eine Idee, wie man dem auf die Spur kommen kann? Alle anderen Dateien in dem Archiv scheinen jedenfalls in Ordnung zu sein.

Nachtrag: Wenn ich die Datei bearbeiten sollte, kann ich dann auch Zeilenumbrüche einfügen, ohne dass LO meckert? Oder muss alles in einer Zeile bleiben? Dann hätte ich kaum Chancen, das Ganze zu bearbeiten, weil die Editoren alle irgendwann die Zeilen umbrechen, weil sie zu lang sind.

[DrMartinus]

Ich habe gerade xmlstarlet über die Datei laufen lassen, demnach ist die Datei valid.

Mir kam auch der Gedanke, dass ich sonst ja immer auf die komprimierte Datei geschaut habe, die natürlich deutlich kleiner ist als die unkomprimierte Datei. Ich habe deswegen noch einmal in die Originaldatei geschaut, da ist content.xml 1,7 MB groß. Ich glaube nicht, dass ich in den letzten Stunden, in denen ich an der Datei gearbeitet habe, über 50 MB an Daten hinzugefügt habe... Eigentlich habe ich nichts hinzugefügt, sondern nur geändert. Allerdings habe ich "Änderungen aufzeichnen" eingeschaltet, von daher könnte es theoretisch zu einer Verdoppelung oder vielleicht auch Verdreifachung der Datenmenge kommen, aber eben nicht zu einer Vergrößerung um das Dreißigfache, oder?

[DrMartinus]

Und noch eine Anmerkung:

Ich habe die Datei jetzt mal mit LibreWolf öffnen können, da sieht es deutlich besser aus, die XML-Tags sind ordentlich angezeigt, es ist nicht einfach nur alles eine Zeile mit unheimlich vielen Buchstaben. Da fiel mir jetzt auf, dass ab einem bestimmten Punkt vor einem Texteintrag sehr viele solcher Einträge stehen:

Code: Alles auswählen

<text:alphabetical-index-mark-start text:id="IMark93853945201424"/>
<text:alphabetical-index-mark-start text:id="IMark93853934879264"/>
<text:alphabetical-index-mark-start text:id="IMark93853934890656"/>
<text:alphabetical-index-mark-start text:id="IMark93853934899200"/>
<text:alphabetical-index-mark-start text:id="IMark93853934907744"/>

Über'n Daumen gepeilt sind es mehr als 100, die da untereinander angezeigt werden, bis wieder ein Stück Text kommt. Kann das die Ursache für das Problem sein?

[juribel]

Dies ist jetzt keine direkte Hilfe, aber in Zukunft würde ich die Dateien nicht im .odt-Format, sondern als .fodt speichern. Da steht (natürlich) dasselbe drin, aber nicht komprimiert und "flach", also alles in einer Datei ohne Ordnerhierarchie. Solche Dateien kann man im Falle des Falles sogar (eine Sicherungskopie vorausgesetzt) mit einem üblichen Texteditor bearbeiten. Nach meiner Erfahrung ist das .fodt-Format aber sehr robust. Man muss sich halt mit einem Vielfachen der Dateigrösse anfreunden, aber dafür laden und speichern solche Dateien oft schneller.

[DrMartinus]

Dies ist jetzt keine direkte Hilfe, aber in Zukunft würde ich die Dateien nicht im .odt-Format, sondern als .fodt speichern.

Hm, das ist interessant, das wusste ich noch nicht. Ich werde das mal ausprobieren.

Da ich mit der Datei noch eine Weile beschäftigt war, will ich hier kurz noch erzählen, wie ich die Datei wieder hergestellt habe. Das Problem scheint jedenfalls bei dem Aufzeichnen der Änderungen gelegen zu haben. Nachdem ich das abgestellt hatte, ging alles reibungslos, aber das ist natürlich nicht im Sinn des Erfinders, denn ich finde diese Funktion gut und würde sie gerne auch nutzen.
Also: die besagten Zeilen in der content.xml-Datei

Code: Alles auswählen

<text:alphabetical-index-mark-start text:id="IMark93853934879264"/>

haben immer auch einen korrespondierenden Eintrag

Code: Alles auswählen

<text:alphabetical-index-mark-end text:id="IMark93853934879264"/>

, beide sind vor bzw. nach einem Textschnipsel (dem geänderten, vermute ich) angeordnet. Ich fand heraus, dass gegen Ende des Abschnittes, in dem die Änderungen aufgezeichnet sind, diese index-marker falsch herum angeordnet waren. Auf

Code: Alles auswählen

<text:alphabetical-index-mark-start text:id="IMark123456"/>
irgendein Text
<text:alphabetical-index-mark-end text:id="IMark123456"/>

folgte ein Block dieser Art:

Code: Alles auswählen

<text:alphabetical-index-mark-end text:id="IMark123456"/>
irgendein Text
<text:alphabetical-index-mark-start text:id="IMark123456"/>

Das war vermutlich die Ursache dafür, dass die Datei als beschädigt und nicht reparierbar angesehen wurde. Anzumerken ist noch, dass die Anzahl der Einträge exponentiell anstieg. Beim letzten Eintrag hatte ich um die 15000 (fünfzehntausend) solcher indexmarker in nur einem Bereich (also nur start oder nur end). Es wiederholten sich immer die vom vorherigen Eintrag, und dazu kamen noch ein paar tausend neu. Offenbar geschah das ab einem bestimmten Punkt, denn am Anfang von content.xml hatten die Einträge immer nur ein solches index-mark-start und index-mark-end Paar um sich. Dann ging es irgendwann los mit 5, dann 30, dann 146 usw. Ich habe es nicht genau dokumentiert, oder gezählt, aber wie gesagt, die Zahl stieg exponentiell und nicht linear. Es ist klar, dass ich keine 17.000 Änderungen an dem Dokument gemacht hatte, und ich war auch der einzige, der daran gearbeitet hat.
Ich habe deswegen alle Einträge bis auf einen um jeden "Textblock" gelöscht. Das Ergebnis war allerdings nicht so prickelnd. Ich konnte die Datei zwar wieder öffnen, aber es gab plötzlich sehr viele Leerstellen im Text verstreut, manchmal mitten in einem Wort oder einer Zahlenreihe, häufig auch neben einem weichen Zeilenumbruch oder einer weichen Leerstelle. Nun wollte ich da ja gerade keine festen Leerstellen haben, also musst ich die löschen (sicherlich ein paar hundert, vielleicht sogar an die tausend). Das ließ sich auch nicht mit Suchen/Ersetzen lösen, denn gewollte Leerstellen wollte ich ja nicht entfernen, und ich habe nicht herausgefunden, wie ich in der Suche weiche Leerstellen oder Zeilenumbrüche suchen kann (sonst hätte ich nach LWL gesucht und gegen W ersetzt, wobei L für eine "harte" Leerstelle steht und "W" für eine weiche Leerstelle.
Ich ließ die Funktion, Änderungen aufzuzeichnen, nach der ersten händischen Reparatur noch angeschaltet, was ich bald bereute. Aber ich war gewarnt und arbeitete vorsichtiger. Doch beim ersten Mal war ich noch etwas unbedarft und achtete nicht darauf, dass das Speichern länger dauerte. Erst bei der dritten Runde achtete ich auch darauf, weil es doch ein Indikator für einen Fehler im Aufbau des Dokuments zu sein schien. Als das Speichern wieder länger als 5 Minuten dauerte, wusste ich also, was das bedeutete, und ging wieder in die content.xml Datei und habe wieder die überbordenden index marker entfernt. Da das dann aber schon nach einigen wenigen Änderung erneut zum Problem wurde, habe ich schließlich alle Daten mittels copy&paste in eine neue Textdatei kopiert und dort auf das Speichern der Änderungen verzichtet. So ging die Arbeit dann recht mühelos voran.
Übrigens hatte ich ja das automatische Speichern zunächst angeschaltet, und ich dachte, dass LO hängen würde, als es beim ersten Mal so elend lange brauchte (zuerst 10 Sekunden, dann 1 Minute, dann 5 Minuten, dann 20 Minuten, dann 1 Stunde, maximal dauerte das Speichern dann ca. 8 Stunden). Nach der ersten Wiederherstellung hatte ich in einem Fall tatsächlich abgewartet und LO nicht mit Brachialgewalt beendert, war ins Bett gegangen, und am nächsten Tag sah ich, dass der Speichervorgang um 2 Uhr nachts geendet hatte - gegen 18 Uhr hatte der Speichervorgang begonnen. Dabei waren jetzt keine Unmengen an Daten geschrieben worden, die Datei war von etwas mehr als 2 MB auf 54 MB angewachsen, wofür ich sonst auch nur ein paar Sekunden zum Speichern brauche - vermutlich hatte LO da noch viele Rechenaufgaben zu lösen versucht.
Ich weiß nicht, ob ich einen Bugreport schreiben soll, meist endet es ja doch ohne Ergebnis, weil andere es nicht nachvollziehen können. Die Datei, in der dieses Verhalten auftrat, kann ich nicht zum Testen zur Verfügung stellen wegen DSVGO, da sind viele private Informationen von anderen Personen enthalten. Also hier nur ein Abschlussbericht, falls anderen Ähnliches widerfährt.

Und noch ein Nachtrag: Original speichert LO die Inhalte in content.xml ja ohne Zeilenumbruch. Ich habe dies so gelöst, dass ich in einem entsprechenden Texteditor die Zeichenfolge "><" gegen ">Zeilenumbruch<" ausgetauscht habe, wobei Zeilenumbruch natürlich mit dem entsprechenden Code eingegeben werden muss. Das hat das Ganze dann deutlich übersichtlicher gemacht, und LO hat mit den Zeilenumbrüchen keine Probleme.