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.)