Description: Open any file, edit it, stop Writer with ~^Del>TaskManager/LibreOffice>EndTask (under Windows). (In real life, this might be a computer or LibreOffice crash.) Restart LibreOffice; it recovers the file. OK. Do the same with a removable medium, but remove medium (USB key) before restarting LibreOffice (In real life, this might be a cloud drive which has not been restarted since the computer was.): it fails to recover the file, of course (*file* does not exist). Exit LibreOffice, re-insert the USB key (or restart the cloud drive), then restart LibreOffice; it fails again; it should not, since *file* now exists. Steps to Reproduce: 0: Open any file; 1: stop Writer with (under Windows) ~^Del>TaskManager/LibreOffice>EndTask. (In real life, this might be a computer or LibreOffice crash.) 2: Restart LibreOffice; it recovers the file. OK. 3: Open any file from a removable medium (USB key), stop Writer with (under Windows) ~^Del>TaskManager/LibreOffice>EndTask; 4: restart LibreOffice (In real life, this might be a cloud drive which has not been restarted since the computer was.): it fails to recover the file, of course (*file* does not exist). 5: Exit LibreOffice, re-insert the USB key (restore the removableMedium), then restart LibreOffice; it fails again; it should not, since *file* now exists. Actual Results: Recovery fails even though file is available. On top of it, Writer never forgets the failed recoveries and keeps presenting all of them at every restart. Expected Results: Recovery should succeed after file has been made available. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-US Calc: CL
I confirm it with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 69d0be09ad81935f7da4b6f8d036c3562357d068 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Steps: 1. Open document from USB-Stick, edit something 2. Quit LO with Task Manager Szenario A: 3. Open LO and choose auto recovery => Works Szenario B: 4. Remove USB-Stick 5. Re-insert USB-Stick 6. Open LO and choose auto-recovery => Works Szenario C: 7. Remove USB-Stick 8. Open LO and choose auto-recovery => Doesn't work (expected), but auto-recovery finished 9. Close LO 10. Re-insert USB-Stick 11. Open LO and choose auto-recovery => Doesn't work Perhaps it is a bug. If auto-recovery starts in step 11 (alsthough it has been finished in step 8) it should work.
I'm not sure how LO is supposed to know what is removable media and what isn't. I certainly wouldn't want LO to constantly keep and check for recovery files that have "gone missing" for some reason.
(In reply to Dieter from comment #1) > Szenario C: > 7. Remove USB-Stick > 8. Open LO and choose auto-recovery => Doesn't work (expected), but > auto-recovery finished At this point (in Ubuntu/gtk3) with an UNMODIFIED file, I got multiple error notices that the file could not be opened. In the end, the dialog indicated "Recovery Failed" and asked me to press Finish. With a modified file, I see the ODF it created in the backup folder, and recovery successfully retrieved the modified contents (after complaining about not being able to open a lock file). If you would have de-selected that file for recovery, the dialog would have indicated "will be discarded". And that makes sense (comment 2). All non-open documents should not show up on the next RecoveryList, and thus it perhaps should report "Recovery Failed - will be discarded". A windows developer is probably going to need to look into how the RecoveryList is created in this scenario. Does a "task manager kill" trigger a SessionSave in Windows? If this is just a "timed autoRecovery", then one of the steps really needs to be waiting for the creation of the autorecovery file. (If this is not created, then you are just "recovering" from the file saved on the USB - which is no different from an "open". In that case, this is a WONTFIX or WORKSFORME since without a timed recovery file, szenario A and B will no longer request a recovery.)
I'm tempted to close this bug report, but I'll leave it open. To resolve this would require an incredible amount of redesign of the autorecovery/session save.
I think I have to close this bug report. 1.) LO does not do session management (in case no autoSave file is stored) 2.) The removeableMedium is irrelevant in terms of restoring from autoSave (assuming the default backup directory - not autoSaving into the original folder). The autorecovery file is stored locally, and thus can be recovery regardless of whether the original file is still available or not. > On top of it, Writer never forgets the failed recoveries > and keeps presenting all of them at every restart. I believe this aspect has been fixed since 24.2. I tested this with 26.8+ using Linux and a debug development build 1.) used LO to save a file on USB. 2.) waited for autosave to complete - so there really is something to recovery 3.) killed LO (with a Ctrl-C) and unmounted USB 4.) restarted LO. - it tries to recover - complains it cannot lock the file - so I 'open read-only' or 'Notify' - it recovers nicely as read-only, and then I can 'save as' wherever I desire. The only time recovery 'fails' is if there was no autosave backup created yet. At that point it is simply a 'session save' recovery attempt, and not a data-loss issue. And since the file simply is not available during this recovery 'session', it gets dropped from future consideration. That is exactly what ought to happen. > it fails again; it should not, since *file* now exists. Ultimately, I think OPs complaint is about the repeated requests to recover a file. Those repeated requests have stopped, and the autorecovery process is much smoother than when he reported. Closing as (assumed) FIXED by tdf#57414.