Bug 77239 - Other: AutoRecovery does not Work Correct if Document has not been Saved Initially by the User
Summary: Other: AutoRecovery does not Work Correct if Document has not been Saved Init...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.2.2.1 release
Hardware: Other Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 89247 (view as bug list)
Depends on:
Blocks: AutoSave-AutoRecovery-Backup
  Show dependency treegraph
 
Reported: 2014-04-09 12:02 UTC by Harald Koester
Modified: 2017-04-15 15: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 Harald Koester 2014-04-09 12:02:57 UTC
Problem description: 

Steps to reproduce:

[1] Start LibreOffice and create a new text document.
[2] Enable option “Load/Save > General > Save > Save AutoRecovery information” and set time period to some minutes.
[3] If enabled disable option “Load/Save > General > Save > Automatically save the document too”.  Due to bug 76950, you have to close and restart LibreOffice again if you change this option.
[4] Crash LibreOffice according bug 75898:
     (a) Insert table with one row
     (b) Select all (Ctrl-A)
     (c) Click "Insert Row" twice
LibreOffice crashes. Recovery dialogue is displayed: The user is informed, that his “files will be saved and recovered next time LibreOffice is launched”.
[5] Click OK: LibreOffice is closed and relaunches after some seconds with a recovery dialogue.
[6] Click “Start Recovery >“: A message is displayed “The file '$(ARG1)' is corrupt and … “. 
Either the message at step 4 (“save and recover”) or the message at step 6 (“corrupt”) is wrong.
Expected: If message at step 4 is wrong, the user should be informed that “the files will be saved and LibreOffice _can_ _try_ to recover them next time LibreOffice is launched”. In this case the message at step 6 is correct without the file name [“$(ARG1)”]. In the other case, if the file is not corrupted the message at step 6 should not be displayed and the file should be recovered immediately. 
[7] Click “Yes” in order to try to repair the file. Another message is displayed: “The file '$(ARG1)' could not repaired and therefore cannot be opened”. The file name is again not correct. Expected: “Untitled 1.odt”.
[8] Click OK and then click Finish. Surprise: Another message is displayed: “The automatic recovery process was interrupted.” What is correct now? Is it possible to recover the file or not?! Either the message at step 7 or at step 8 is wrong.
[9] Click Save. A file with the file name “untitled_108odt” without a file extension is saved.  Expected: File name should be “Untitled 1.odt”. 
[10] Open recovered file. The content has been recovered successfully.

-----

The behaviour is equal if you wait after step 4a until the AutoRecovery information has been saved. 

The behaviour is correct if you save your document after step 4a.

I also tested the behaviour if LibreOffice is cancelled by the Task Manager and if the power supply of the computer is switched off. In both cases a recovery is performed, but the document is empty. This is formally correct, hence a recovery information has not been saved. But it does not really makes sense to recover an empty document.

See also bug 57142, bug 58588 and bug 66162 which also deal with the recovery process.              
Operating System: Windows 7
Version: 4.2.2.1 release
Comment 1 Buovjaga 2014-10-31 13:25:22 UTC
I confirm and set as enhancement.

Win 7 64-bit Version: 4.4.0.0.alpha1+
Build ID: 56019dcb79475606952a954fe732a3109441ffec
TinderBox: Win-x86@39, Branch:master, Time: 2014-10-30_07:27:11
Comment 2 Buovjaga 2015-02-11 19:43:28 UTC
*** Bug 89247 has been marked as a duplicate of this bug. ***
Comment 3 Harald Koester 2017-04-04 09:29:15 UTC
Checked again with version 5.1.6 (Win7). Works for me now. Hence set to RESOLVED.

I'm not sure if bug 89247 (duplicate) is also resolved. 
@Yan Pas, can you please check this?
Comment 4 Yan Pas 2017-04-15 15:34:50 UTC
yes, seems to be fixes