Bug 160988 - Incomplete recovery after crash
Summary: Incomplete recovery after crash
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoSave-AutoRecovery-Backup
  Show dependency treegraph
 
Reported: 2024-05-08 13:29 UTC by Ulrich Windl
Modified: 2024-05-27 17:34 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2024-05-08 13:29:12 UTC
I had opened multiple Writer documents and a Calc document when LibreOffice crashed. As I had auto-save enabled, LibreOffice offered to recover all the documents when restarting it.
However after recovery had finished the first (writer) document has stats like "not yet recovered" while the rest has the check mark (recovered successfully) set.
At that point there was no way to retry recovery or so, so I continued.

The first document showed yesterday's (time of last save) contents, and multiple hours of editing seemed gone!
So I closed the document and re-opened it, hoping recovery would be suggested (that's what Emacs would do BTW). But the document opened without further notice, showing yesterday's content.

Fortunately (in this context only) LibreOffice crashed again while working on the Calc document, and (rather) surprisingly LibreOffice suggested to recover the document that wasn't recovered before. This time it succeeded, and only little of today's work was lost.

It seems that auto-recovery is not as reliable as it should be, and there should be an option to re-try the recovery if is shows a "not yet completed" at the end of automatic recovery.

Version: 7.6.4.1 (x86) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL threaded
Comment 1 Stéphane Guillou (stragu) 2024-05-27 14:51:43 UTC
Justin, with your recent work on autorecovery, any idea how to proceed with this report? No idea how to attempt reproducing such a scenario.
Comment 2 Justin L 2024-05-27 17:34:22 UTC
If LO failed to recover the document the first time, there is no reason to think it would succeed on future tries. (It simply tries to load the document IIRC.)

I agree that the wording is a little strange at the second dialog (which now only shows up if one or more failed to recover). IIRC it is basically asking for permission to delete the document it failed to recover, and saying no - don't delete it - will save it to the documents folder before continuing?

So if this happens again, the safest way to proceed is to wait at that second dialog and grab a copy of the ODF document it failed to recover. If that document is attached to this bug report, there is at least some hope that a problem can be identified and fixed.

(In reply to Ulrich Windl from comment #0)
> (rather) surprisingly LibreOffice suggested to
> recover the document that wasn't recovered before. This time it succeeded,
> and only little of today's work was lost.
That's not surprising. You indicate there are unsaved changes on it, so I would expect it to attempt recovery. Obviously today's changes didn't trigger whatever caused yesterday's save failure.