https://bugs.documentfoundation.org/show_bug.cgi?id=163249
Bug ID: 163249
Summary: Spreadsheet repair appears to fail every time, despite
backup available; final status confusing
Product: LibreOffice
Version: 24.8.1.2 release
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: ddascalescu+freedesk...@gmail.com
Created attachment 196832
--> https://bugs.documentfoundation.org/attachment.cgi?id=196832&action=edit
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.
--
You are receiving this mail because:
You are the assignee for the bug.
