Description: L/O Writer (vers 7.4.2.3) is no longer recovering unsaved files. I do not know when I first noticed that it does not, but it has been several months (several versions earlier). Finally, I uninstalled the current version, and installed two old versions (7.0.0.0 and 7.1.0.0) that I was reasonably sure did not have the problem because they were before I encountered the problem. However, upon installing the old versions, they had the same problem, so now I am baffled. After uninstalling them, and reinstalling 7.4.2.3, the problem still exists. Steps to Reproduce: Step 0 – Setup I have one saved document (in a folder on the Desktop), and 4 unsaved, open documents (pic 01). There is the saved document (named document 1.odt) (pic 02) I have pics of unsaved documents (pics 03-06) all filled with text. Step 1 – End task Then I kill LibreOffice using “End task” on Task Manager (pic 07). I have used this often, with unsaved documents always being recovered upon restarting LibreOffice. Step 2 – Restart LibreOffice Now, when I restart LibreOffice (pic 08), it looks like it is going to recover the documents. I click “Start” which brings up a screen that says that all documents were “Successfully recovered” (pic 09). Step 3 – View the results Actual Results: When you look at the "recovered" documents, the saved document looks good (pic 10), but all of the unsaved documents are empty with the text “(Remote)” added to the temporary, unsaved document name (pics 11-14). Expected Results: I would expect all recovered documents to be as they were before. Reproducible: Always User Profile Reset: No Additional Info: This is my first bug report to LibreOffice. Safe Mode did not resolve the problem. It didn't try to recover documents at all. So, as instructed, I did not try to "reset" UserProfile.
Created attachment 183205 [details] setup to reproduce
Created attachment 183206 [details] saved file
Created attachment 183207 [details] unsaved file
Created attachment 183208 [details] End LibreOffice task using Task Manager
Created attachment 183209 [details] recovery begins
Created attachment 183210 [details] recovery says that it's successful
Created attachment 183211 [details] saved file is recovered
Created attachment 183212 [details] unsaved files are NOT recovered
Pic numbers in description no longer relate to attachments. There should be a way to edit the bug report, but I don't see one.
You saved one file before killing the process. Did you changed content after you have saved something in the file? Is this new content also available in the recovered document? Have tested this and no new content was available here. What did you choose in Tools → Options → Load/Save → General → Save AutoRecovery Information every: … minutes? Have set this to 2 minutes, waited 3 minutes after changing content or created a new unsaved document with new content. All unsaved content is there, also the content of the unsaved document. Tested with Version: 7.4.3.1 / LibreOffice Community Build ID: 3793858a34d8fef5b92f8fee233f97766f05e281 CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded So I can't confirm a buggy behavior here.
(In reply to Robert Großkopf from comment #10) > You saved one file before killing the process. Did you changed content after > you have saved something in the file? Is this new content also available in > the recovered document? -------------------------------------------------------------- RESPONSE: Changed information in "saved file" is also lost. -------------------------------------------------------------- > > Have tested this and no new content was available here. > > What did you choose in Tools → Options → Load/Save → General → Save > AutoRecovery Information every: … minutes? > Have set this to 2 minutes, waited 3 minutes after changing content or > created a new unsaved document with new content. > All unsaved content is there, also the content of the unsaved document. > -------------------------------------------------------------- RESPONSE: Did not change AutoRecovery minutes from default. Is set at 10 minutes, however default is not activated. Activated, retested, no change. Still receiving original problem results. Using default settings, problem did not previously exist. -------------------------------------------------------------- > Tested with > Version: 7.4.3.1 / LibreOffice Community > Build ID: 3793858a34d8fef5b92f8fee233f97766f05e281 > CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) > Locale: de-DE (de_DE.UTF-8); UI: en-US > Calc: threaded > > So I can't confirm a buggy behavior here. -------------------------------------------------------------- RESPONSE: The screenshots that I provided prove buggy behavior. These results were with a clean install of: Version 7.4.2.3 (Current Release) Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf Windows 10 current version --------------------------------------------------------------
Matt, these recovery files should be saved in (I think) %APPDATA%\libreoffice\4\user\backup. You should be able to inspect them before you crash LO. Make a note of the file's timestamp for each of these recovery files before you crash LO. (LO does attempt to save files before an emergency shutdown - perhaps that is failing if it does manage to run at all in this case?) Any idea why LO might think you are dealing with remote files? Is your profile on a network? Are you dealing with webdav or any server based storage? I could not reproduce -opened a file from desktop and made modifications -started 4 new documents and filled with text ("lorem", then press F3) -wait until autosave timer kicked in - saw instdir/user/backup -rw------- 1 user user 12895 Jul 19 08:28 junk.docx_0.odt -rw------- 1 user user 35448 Jul 19 08:29 untitled_0.odt -rw------- 1 user user 35446 Jul 19 08:29 untitled_1.odt -rw------- 1 user user 35451 Jul 19 08:29 untitled_2.odt -rw------- 1 user user 35447 Jul 19 08:29 untitled_3.odt -Ctrl-C to end my development run. Restarted LO and all 5 documents recovered OK
Maybe related to bug 95229
Is this the same as bug 124213? Said to be a regression from around 5.2