Writer: allgemeiner Ein-Ausgabefehler beim Speichern zerstört Dokument

de-users
#1

Hallo Liste,

ich versuche mit LO 5.0.4 Writer auf einem Win7 PC ein bereits seit 3 Jahren bestehende und bisher immer problemlos zu bearbeitende odt-Datei zu verändern und sie wird mir beim Speichern zerstört.

Das erste Öffnen geht problemlos. Schließen ohne Veränderung klappt ebenfalls noch.
Bei "speichern unter..." oder beim Speicherversuch nach irgendeiner Veränderung läuft der Balken am unteren Rand bis zum Ende durch und mit der Meldung "Fehler beim Speichern. Allgemeiner Ein-/Ausgabefehler." beendet sich LO komplett. (Die ~lock-Datei für den neuen Namen existiert danach.) Beim erneuten Öffnen gelingt die Wiederherstellung zunächst noch. Aber der nächste Versuch die Datei zu schließen, endet ebenfalls wieder mit einem Absturz und dann ist keine Wiederherstellung mehr möglich sondern LO erkennt die Datei als "zerstört" und ein Reparaturversuch ergibt ein leere Datei.

Eine neu angelegte Testdatei konnte ich problemlos öffnen/verändern/speichern.
Andere, ältere odt-Dateien erleben das gleiche Schicksal.
Eine Deinstallation/Neuinstallation war ohne Wirkung.
Deinstallation von LO 5.0.4 und Installation von LO 4.4.7 blieb ebenfalls wirkungslos.
Gleiche Symptome auch bei anderem Nutzerkonto (mit Admin-Rechten)
Eine Kopie (Strg-C/V) der Inhalte in eine neue Datei löst das Problem nicht.

Wo könnte der Fehler noch liegen?

Grüße

#2

Hallo Roland,

ich versuche mit LO 5.0.4 Writer auf einem Win7 PC ein bereits seit 3
Jahren bestehende und bisher immer problemlos zu bearbeitende odt-Datei
zu verändern und sie wird mir beim Speichern zerstört.

Das erste Öffnen geht problemlos. Schließen ohne Veränderung klappt
ebenfalls noch.
Bei "speichern unter..." oder beim Speicherversuch nach irgendeiner
Veränderung läuft der Balken am unteren Rand bis zum Ende durch und mit
der Meldung "Fehler beim Speichern. Allgemeiner Ein-/Ausgabefehler."
beendet sich LO komplett. (Die ~lock-Datei für den neuen Namen existiert
danach.) Beim erneuten Öffnen gelingt die Wiederherstellung zunächst
noch. Aber der nächste Versuch die Datei zu schließen, endet ebenfalls
wieder mit einem Absturz und dann ist keine Wiederherstellung mehr
möglich sondern LO erkennt die Datei als "zerstört" und ein
Reparaturversuch ergibt ein leere Datei.

Eine neu angelegte Testdatei konnte ich problemlos
öffnen/verändern/speichern.
Andere, ältere odt-Dateien erleben das gleiche Schicksal.
Eine Deinstallation/Neuinstallation war ohne Wirkung.
Deinstallation von LO 5.0.4 und Installation von LO 4.4.7 blieb
ebenfalls wirkungslos.
Gleiche Symptome auch bei anderem Nutzerkonto (mit Admin-Rechten)
Eine Kopie (Strg-C/V) der Inhalte in eine neue Datei löst das Problem nicht.

Wo könnte der Fehler noch liegen?

Die zwei üblichen Standard-Nachfragen dazu:

1. Wie verhält sich das Problem in einem leeren neu erstellten
Nutzerprofil?

2. Wo kann man so eine problematische Datei downloaden?

#3

Hallo Werner,

ich bin mir keiner Verbindung zu externen Daten bewusst. Unter "Bearbeiten --> Verknüpfungen" findet sich nichts, d.h. der Menüpunkt bleibt inaktiv.

Gruß
Roland

#4

Hallo Franklin,

zu 1.: gleiches Verhalten der Datei in einem neu angelegten Benutzerkonto.

zu 2: hier: https://www.dropbox.com/s/12s0pgswiw0gtw1/Skript%20Mathe%20Q.odt?dl=0

Grüße
Roland

#5

Hallo Roland,

zu 1.: gleiches Verhalten der Datei in einem neu angelegten Benutzerkonto.

zu 2: hier:
https://www.dropbox.com/s/12s0pgswiw0gtw1/Skript%20Mathe%20Q.odt?dl=0

Oha ... 158 Seiten mit rd. 1.000 Objekten, insgesamt knapp 12 MB
groß ... vielleicht ist LibO damit doch ein bisschen überfordert?

Zumindest kann ich hier unter Win7Ult64 mit Lib 5.0.4.2 bestätigen,
dass beim Speicherversuch dieser Datei nach einer kleinen Ergänzung
am Schluss soffice.bin einen Runtime-Error in der Microsoft Visual
C++ Runtime Library verursacht und damit abstürzt.

#6

Hallo Franklin,

ich hatte gerade die Chance auf einem andern PC mit LO 4.3.5 einen Versuch zu starten.

Dort verhielt sich die Datei problemlos! Öffnen, Speichern, kleine Änderung, ...

Ich versuche mal sie dort zu "zerlegen" und häppchenweise mit LO 5.0 wieder zu öffnen.

Grüße.

#7

Kann es sein, dass die alte Version mit so großen Dateien besser zurecht kommt als die neue?
Halbiert lässt sich die Datei auch in LO 5.0 wieder bearbeiten.

Das hätte ich nicht gedacht, dass ich mal ein aktuelles Textverarbeitungsprogramm "überfordern" würde...

Danke für den Tip!!!!
Grüße

#8

Hallo Roland,

habe mir interesseshalber die Datei runtergeladen und mit LO Version: 5.0.4.2 (x64) auf WIN 10/64Bit geöffnet. Sie war schreibgeschützt, weshalb ich eine Arbeitskopie öffnete und neu speicherte. Öffnen und speichern ging einwandfrei, auch nach dem Einfügen einer Fusszeile mit Seitenzahlen. LO zeigte für ca. 10 Sekunden "Keine Rückmeldung" dann war alles OK.

Mit bestem Gruss,
Jürgen

#9

Hallo *,

das scheint wieder ein spezielles Windows-Problem zu sein. Ich kann
die Datei hier locker in wenigen Sekunden öffnen, ändern und
abspeichern. Keine Probleme beim erneuten Öffnen, nichts. Die Größe
dürfte nicht die Ursache sein. Ich arbeite beim Base-Handbuch mit
einem Globaldokument, das, als *.odt mit allen Dateien abgespeichert,
eine ähnliche Größe hat.

Mein System: OpenSUSE Leap 42.1, 64bit rpm Linux.
Getestet mit LO 4.4.7.2 und LO 5.0.4.2

Gruß

Robert

#10

Hallo Robert,

Hallo *,

das scheint wieder ein spezielles Windows-Problem zu sein.

Na ja, ich schrieb ja, dass es hier einen Runtime-Error in der
Microsoft Visual C++ Runtime Library gibt, und die wird es
vermutlich unter Unixen nicht geben, oder?

Mein System: OpenSUSE Leap 42.1, 64bit rpm Linux.
Getestet mit LO 4.4.7.2 und LO 5.0.4.2

Robert

.... und tschüss

            Franklin

#11

Ich arbeite beim Base-Handbuch mit
einem Globaldokument, das, als *.odt mit allen

Dateien abgespeichert,

eine ähnliche Größe hat.

da kann man sich nur bedanken !!!!

Frank

#12

Vielen Dank an alle hier fürs Mitdenken!

Ich ordne das im Moment als Problem meines Win7-PCs ein und arbeite mit der gesplitteten Datei weiter.
Sollte ich mal auf Win10 updaten starte ich einen neuen Versuch.

Grüße
Roland

#13

Hallo Roland,
es wird dir nicht helfen und ist auch nur der Vollständigkeit halber: ("viel gescholten") WinXP SP3 + LO 5.0.3.2 geht ohne Probleme... ...und auch ohne "Pausen" im "Fortschrittsbalken"...

Gruß
Karsten

#14

Hallo Karsten,

("viel gescholten") WinXP SP3 + LO 5.0.3.2 geht ohne Probleme...
...und auch ohne "Pausen" im "Fortschrittsbalken"...

Nur der Vollständigkeit halber: Unter einem anderen Desktop-Rechner
mit Win7Home32 und LibO 4.1 habe ich mit der Datei hier ebenso wenig
Probleme wie in einer 32-bit-Manjaro-Linux-VM mit LibO 4.4.7 auf
meinem Haupt-Laptop. Direkt auf dem Haupt-Laptop erfolgt jedoch der
Absturz unter Win7Ult64 mit LibO 5.0.4 reproduzierbar - mal mit, mal
ohne sichtbare Fehlermeldungen.

#15

Hallo Franklin,

Nur der Vollständigkeit halber: Unter einem anderen
Desktop-Rechner mit Win7Home32 und LibO 4.1 habe ich mit der Datei
hier ebenso wenig Probleme wie in einer 32-bit-Manjaro-Linux-VM mit
LibO 4.4.7 auf meinem Haupt-Laptop. Direkt auf dem Haupt-Laptop
erfolgt jedoch der Absturz unter Win7Ult64 mit LibO 5.0.4
reproduzierbar - mal mit, mal ohne sichtbare Fehlermeldungen.

Ist das dann vielleicht noch klarer ein Problem der Win-64bit-Version?
Dann wäre es doch eventuell möglich, einmal die Win-32bit-Version zu
testen ...

Gruß

Robert

#16

Hallo Robert,

Nur der Vollständigkeit halber: Unter einem anderen
Desktop-Rechner mit Win7Home32 und LibO 4.1 habe ich mit der Datei
hier ebenso wenig Probleme wie in einer 32-bit-Manjaro-Linux-VM mit
LibO 4.4.7 auf meinem Haupt-Laptop. Direkt auf dem Haupt-Laptop
erfolgt jedoch der Absturz unter Win7Ult64 mit LibO 5.0.4
reproduzierbar - mal mit, mal ohne sichtbare Fehlermeldungen.

Ist das dann vielleicht noch klarer ein Problem der Win-64bit-Version?

Du meinst, dass auf meinem 64-bit-BS auch ein 64-bit-LibO läuft?
Nein, hier ist LibO überall nur in der 32-bit-Version installiert.

Aber möglicherweise hängt es tatsächlich - neben Timing-Problemen
der 5er-LibO-Version auf meinem 64-bit-Laptop-Rechner - auch mit der
Tatsache zusammen, dass das BS 64-bittig ist ...

Dann wäre es doch eventuell möglich, einmal die Win-32bit-Version zu
testen ...

Robert

.... und tschüss

            Franklin

#17

Ähnliches hatte ich auf einem meiner Debianrechner. Speichern dauerte
ewig, meist mit Absturz, das Öffnen von Dokumenten konnte klappen aber
genauso gut auch mit Absturz enden.
Und egal, welche LO-Version ich probierte, die Probleme nahmen eher zu.
Ansonsten funktionierte auf dem Rechner aber alles ordentlich. Nur
eben LO, ...

Ich bin dem aber lange nicht nachgegangen, weil das nicht mein
Hauptrechner für Schreibkram ist. Letztlich hat's mich aber doch
irgendwie gewurmt und ich habe LO mal auf 5.1.0.1 gebracht.

Die Symptome blieben. Also LO beendet und das Benutzerprofil
umbenannt, so dass LO beim nächsten Start ein neues anlegte.
Lediglich die eigenen Dokumentvorlagen fügte ich wieder ein.

Tja, was soll ich sagen? Seitdem keine Abstürze mehr, schnelles
Speichern funktioniert und selbst richtig große Dokumente funktionieren
wieder so, wie auf allen anderen Rechnern.

https://wiki.documentfoundation.org/UserProfile/de

Von einem Bekannten, der LO auch unter Windows betreibt, weiß ich, dass
der ähnliche Probleme auf nur einem seiner Rechner hatte. Auch hier
half ein neues Benutzerprofil.

Warum es da mitunter klemmt, würde mich mal interessieren. Möglich,
dass etwas durcheinander kommt, wenn man jahrelang immer weiter
upgradet. Warum das dann aber nicht auf allen Rechnern Probleme
bereitet? Und bei mir ausgerechnet auf dem Rechner nicht, auf dem ich
seit Jahren alle paar Wochen die neueste Version fahre?