Created attachment 196832 [details] Screenshot 0 - save options When attempting to recover/repair files after a crash, LibreOffice appears to systematically fail, with the error message below: > The file [...] is corrupt and therefore cannot be opened. LibreOffice can try to repair the file. > The corruption could be the result of document manipulation or of structural document damage due to data transmission. > We recommend that you do not trust the content of the repaired document. Execution of macros is disabled for this document. > Should LibreOffice repair the file? I find this behavior perplexing, because I've enabled autosaving the document every 10 minutes, AND creating backup copies. On the documents in question, no edits had been performed in the last 20+ minutes before the crash. Here is the information I can provide: 1. Because LO and/or KDE still keep crashing at least once a week, I've checked the following settings in Load/Save -> General (see attached screenshot 0): [x] Save AutoRecovery information every: 10 minutes [x] Automatically save the document instead [x] Always create a backup copy [x] Place the backup in the same folder as document 2. The crash occurs 3. I restart LO and see a list of corrupted documents, then the error above (screenshot 1) 4. I look at the file sizes and notice one .ods document is ~2.5% larger than its .ods.bak (e.g. 1,745,811 vs. 1,702,908 bytes), and one is slightly smaller (36,243 vs. 36,959) but the pairs have the same timestamp (as expected). The difference in size doesn't make sense, because I enabled saving backup copies, they have the same timestamp as the original, and no edits had been performed in more than 2 auto-save periods before the crash, so the .ods and .ods.bak should be identical. 5. Slightly worried about the "do not trust the content of the repaired document" at step 3, I answer the prompt "Yes" anyway. Then I see a message that the "original document [was] recovered" (screenshot 2). Does "original" mean LO used the .ods.bak file? In that case, it should not unnecessarily worry the user about the content of the document; instead is should directly overwrite the .ods with the .ods.bak. 6. After that dialog, I see a new one (screenshot 3), that "The automatic recovery process was interrupted". This is confusing because I don't think I interrupted the process. I had 3 corrupted files in the initial list, expenses.ods had the problem in screenshot 1, I unchecked another document them, and the 3rd was allegedly recovered successfully. Overall, the repair process is confusing an worrisome, and it seems there are no options to safely create backup copies (from within LO). # Some suggestions S1. The auto-recovery settings being two checkboxes can lead to confusing combinations, such as [ ] Save AutoRecovery information every: 10 minutes [x] Automatically save the document instead Can they be re-thought as radio buttons? Document recovery: ( ) automatically save recovery information every X minutes (*) automatically save the documents instead Also, the "Edit document properties before saving" options seems unrelated to autosaving. Should it be moved after the Backup option? (see screenshot 0 - save options suggestions). S2. It seems the .ods.bak file should be identical to the .ods file if more than 2 recovery intervals have passed with no edits. Where did a 42kb difference come from? S3. Corruption shouldn't really happen unless the crash occurred exactly in the middle of saving (which is extremely unlikely, and should be manifested by a smaller file size. Either way, the backup file should not be corrupted (unless the crash happens repeatedly on each save - not the case in this situation, which was a KDE crash). I do assume the backup is created automatically with every auto-save, as suggested by the .ods.bak file having the same timestamp as the .ods.
Created attachment 196833 [details] Screesnhot 1 - corrupt file
Created attachment 196834 [details] Screenshot 2 - apparently succeeded after all?
Created attachment 196835 [details] Screenshot 3 - prompt to save elsewhere
Created attachment 196836 [details] Screenshot 0 - save options suggestions
(In reply to Dan Dascalescu from comment #0) > I do assume the backup is created > automatically with every auto-save, as suggested by the .ods.bak file having > the same timestamp as the .ods. I now think that assumption was incorrect. The .ods.bak file is only created when saving manually.
Still running into this when LO 24.8.2.1 or the OS crashes. After answering "No" to whether LO should repair the corrupt file (Screenshot 1 - corrupt file), I get the message from Screenshot 2, that the original document was recovered. This is clearly a bug. Now every time I see the recovery dialog, I manually copy the file with a new name, go through the recovery motions pointlessly, then overwrite the original. This defeats the purpose of the recovery procedure.
I've been running Calc in Safe Mode because it's 2-3x faster at loading spreadsheets, and I don't see anything I'm missing from "regular" mode. In this mode, Autosave was set to 10 minutes, but "Automatically save the document instead" was UNchecked. "Always create backup copy" was checked as well, but "...in the same folder" was UNchecked. After an OS crash, in the directory containing the file I was working on, I only saw an old backup copy (probably created by Calc in regular mode when the "...in the same folder" option was checked, and my file with a Last Modified timestamp of 3 days ago - clearly not autosaved. But the recovery information was saved SOMEWHERE, because recovery succeeded without any warnings. So that was good. Version: 24.8.3.2 (X86_64) / LibreOffice Community, Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 However at this point I feel safer disabling Autosave altogether and saving manually like in the good old days.
Coincidentally, I found a bug I filed for pretty much the same issue exactly 7 years ago - bug 114508.
Still seeing this bug in 24.8.4.2. Even if I answer "no" at the "do not trust the content of the repaired document" prompt, LO still proceeds with the recovery, and the Status ends up being "original document recovered". Can I trust the file or not now?
(In reply to Dan Dascalescu from comment #0) > > Should LibreOffice repair the file? > > I find this behavior perplexing, because I've enabled autosaving the > document every 10 minutes, AND creating backup copies. On the documents in > question, no edits had been performed in the last 20+ minutes before the > crash. Autosaving just relieves you from pressing ctrl+S, and the backup copies are some kind of a copy before overwriting the document with save. Those options are independent from repairing files. > 4. ...notice one .ods document is ~2.5% larger than its .ods.bak The corruption could play a role here. Ultimately a question to devs and likely not possible to answer without a sample. > 6. After that dialog, I see a new one (screenshot 3), that "The automatic > recovery process was interrupted". I can follow the confusion about the word "interrupted". I guess it means "was not successful". However, the process should work well after bug 114508 was fixed. > # Some suggestions Most of your confusion seems to come from the backup file. It is not meant for recovering but as the previous version of the document. If the recovery process fails you could manually replace the file. > S3. Corruption shouldn't really happen unless the crash occurred exactly in > the middle of saving... Here I fully agree ;-).
Created attachment 204436 [details] proofscreen Environment: Windows 11 64-bit • LibreOffice 25.8.3.2 (x86_64) • LibreOffice 26.2.0.0.alpha1+ (x86_64) Preconditions: Before testing, I enabled all save/recovery options: Save AutoRecovery information every 10 min Automatically save the document instead Always create a backup copy Store backup in the same folder Tested specifically to match the original bug scenario. Steps: Created a new Writer document. Added text. Saved the file → .odt + .odt.bak created. Edited the document again. Forced a crash using Task Manager (End task on soffice.bin). Restarted LibreOffice and checked recovery behavior + file state. Results — 25.8.3.2 stable: Recovery dialog appeared normally. Document restored successfully. No corruption warnings. .odt and .odt.bak identical in size and content. No data loss. Issue not reproducible. Results — 26.2.0.0.alpha1+ dev: No recovery dialog shown after crash. File visible under Recent Documents, opens without issues. Data intact. .odt and .odt.bak identical. Behavior different but still no corruption. Summary:I could not reproduce the corruption or failed recovery described in the original report. Both stable and dev builds handled forced crashes correctly with all autosave + backup options enabled.
(In reply to Volodymyr from comment #11) > Summary:I could not reproduce the corruption or failed recovery described in > the original report. Resolve as invalid? Heisenbugs occur sometimes - and disappear later ;-) I'm pretty sure backup files are not taken for recovery.