Overview: The auto-save functionality appears to stop working after performing a "Save as" operation on an open document. This results in either new data entered being lost upon an application crash, or making AutoRecovery restore the information but with the wrong file name. Steps to reproduce: Note: this is faster to reproduce if the AutoRecovery save frequency is set to 1 minute (so you don't have to wait the default of 15 mins between AutoRecovery backups.) This setting is at Tools -> Options -> Load/Save -> General -> "Save AutoRecovery information every:". Also, pull up the backup directory in Windows Explorer so that you can watch the backup files. The path to this can be found at Tools -> Options -> LibreOffice -> Paths -> Backups. 1. Open a new, blank Writer or Calc document and write some text. Wait for the AutoRecovery save frequency and you should see a new file get created (probably named "untitled_0.odt" or "untitled_0.ods".) 2. Save the file as a new document, write some new text, and then wait for the AutoRecovery save frequency. In the backup file directory, from my testing, one of two things will occur: a: the previous backup file gets deleted and a new one is never created b: a backup file with a name similar to the original document (ex: "untitled_1.odt") exists and will continue to be updated. Depending on which of these occurred, go to either step 3a or 3b below. 3a. Wait multiple iterations of the AutoRecovery save frequency, entering new text in between. The document will appear to auto-save, but the auto-save file will never get created. If the application crashes (or you kill it via the Task Manager) attempts to auto-recover the data will fail, saying that "untitled_0.odt" or similar does not exist. It fails to recover any data entered past the point of the "Save as" in Step 2. 3b. Wait multiple iterations of the AutoRecovery save frequency, entering new text in between. - the backup file should continue to be updated but with the wrong file name. If the application crashes (or you kill it via the Task Manager) attempts to auto-recover the data may succeed, but the document will have the original file name ("untitled_0.odt" or similar.) Save the currently open file again as a new file. From my testing, this always results in 2a above, and you can proceed to step 3a (where auto-save stops working completely.) Similar results occur when you start by opening an existing document as opposed to creating a new one. Actual Results: Inability to recover changes upon the application crashing, despite AutoSave appearing to work successfully. Expected Results: Information as of the last auto-save interval should be restored during AutoRecovery. Build Date and Hardware: Version: 5.0.3.2 Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb7 Windows 10 Professional, x86-64 Additional Builds and Platforms: Untested on other platforms Additional Information: May be related to bug 92151
(In reply to anwilli5 from comment #0) > a: the previous backup file gets deleted and a new one is never created Reproduced. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: 18565a34d6e2768d70462f124c6d6972448efe22 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-23_11:31:57 Locale: fi-FI (fi_FI)
Maybe related with https://bugs.documentfoundation.org/show_bug.cgi?id=95591 ?
Andrew: you assigned this to yourself. Are you going to fix the bug?
Buovjaga: Yes - I think I've identified the cause but I'm still trying to determine what the best solution is. Once I have something I'll submit a patch.
(In reply to Andrew from comment #4) > Buovjaga: Yes - I think I've identified the cause but I'm still trying to > determine what the best solution is. Once I have something I'll submit a > patch. Great :) You can ask for advice on IRC, #libreoffice-dev @ Freenode network or at the developer mailing list: https://lists.freedesktop.org/mailman/listinfo/libreoffice Here are instructions on submitting patches: https://wiki.documentfoundation.org/Development/gerrit
*** Bug 99890 has been marked as a duplicate of this bug. ***
*** Bug 95787 has been marked as a duplicate of this bug. ***
*** Bug 95591 has been marked as a duplicate of this bug. ***
Two short notes: 1. The problem described above starts after a normal manual "Save" as well, not just after "Save as". 2. Auto-Save is actually performed (a temporary file gets created in the backup folder), but it vanishes directly afterwards. Maybe there is an issue with renaming it to the usual backup file schema or with deleting files? Andrew, maybe you can tell what you already found in case others want to help? Win7 x64, LO 5.1.3.2. (Personally I'd make this issue a blocker for 5.2.0 final.)
(In reply to Matthias Basler from comment #9) > Two short notes: > 1. The problem described above starts after a normal manual "Save" as well, > not just after "Save as". > 2. Auto-Save is actually performed (a temporary file gets created in the > backup folder), but it vanishes directly afterwards. Maybe there is an issue > with renaming it to the usual backup file schema or with deleting files? > Andrew, maybe you can tell what you already found in case others want to > help? > > Win7 x64, LO 5.1.3.2. > > (Personally I'd make this issue a blocker for 5.2.0 final.) Matthias, I think you are right - the code paths for SAVE and SAVEAS are essentially the same from an auto recovery perspective, so this likely does affect the 'Save' operation as well. Check out my commit message for an explanation of why this issue happens: https://gerrit.libreoffice.org/#/c/25948/ The fix is actually very simple, assuming my code change is correct. It's still waiting on a code review, though.
Thanks, Andrew. Your technical description on Gerrit sounds sensible. Unfortunately I have no C++ skills, so I leave testing to someone who has. I wonder what is the official way to signal that an issue needs review? (Some special keyword or whatever?)
(In reply to Matthias Basler from comment #11) > Thanks, Andrew. Your technical description on Gerrit sounds sensible. > Unfortunately I have no C++ skills, so I leave testing to someone who has. > > I wonder what is the official way to signal that an issue needs review? > (Some special keyword or whatever?) Gerrit is a review platform so every patch requires review by default.
*** Bug 95535 has been marked as a duplicate of this bug. ***
anwilli5 committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e28b2f9ac3f205db223352cb88eb3546a8e1c0e tdf#96607 'Save as' doesn't update global auto-recovery state It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tested the daily build (on Win7 Prof., 64 Bit) master~2016-06-13_01.19.21_LibreOfficeDev_5.3.0.0.alpha0_Win_x64_en-US_de_ar_ja_ru_qtz.msi The issue is gone, that is, after saving, backup files are still reliably created with postfix numbers iterating between 0 and 1. One thing I'd like to note: I did several test runs. During the first ones I had the impression that AutoSave would now not work correctly *up to the point* when I saved my document. For example I saw a temporary file being created in the <install>\user\backup just to disappear a second later, leaving the backup folder empty. However I have later not been able to reproduce the issue at will, (e.g. by opening my document in a fresh instance, doing some edits and waiting for the next Auto-Save.) So I'd be happy if other people could check for any issues too.
(In reply to Matthias Basler from comment #15) > I tested the daily build (on Win7 Prof., 64 Bit) > master~2016-06-13_01.19.21_LibreOfficeDev_5.3.0.0.alpha0_Win_x64_en- > US_de_ar_ja_ru_qtz.msi That is interesting as Andrew's patch was committed ten days after the build you used was created. This Tinderbox has newer builds: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/
No idea how to explain this. Anyway. I find this page http://dev-builds.libreoffice.org/daily/master/ rather irritating, as there are several builds for each OS, and the folder date (Win-x86_64@62-TDF/, which I looked at) was up-to-date, but the files within were indeed two weeks older. Sorry I didn't notice. Going to test with a recent version again ...
Tested again with the latest Master version downloaded by the "Separate Install GUI" tool (files within dating to previous night). Did several test runs. There were no problems or strange effects concerning AutoSave. Worked as expected. So I approve the bug fix.
I was curious whether OpenOffice had this issue as well, but it turns out that it doesn't. It looks like the issue was due to a change in the LibreOffice code in January of 2014, with LibreOffice 4.2.1.1 being the first release to pull in the code. Updating the earliest affected version for historical purposes.
I was just about to report this same bug, as I have lost many hours of work in very short time. Is there as patch for that?
(In reply to Slack from comment #20) > I was just about to report this same bug, as I have lost many hours of work > in very short time. Is there as patch for that? Look in /tmp for the most recent directory created by LO for its save files: use "file" to find which of the files in there is actually a .odt file; copy the newest one to a new location, and rename it something.odt; open that. It should be the most recent backup copy that LO took. I suggest this, in the hope that some of the work you've done over the last few hours will have been saved there. Good luck! And
I'm sorry to hear about your lost work, Slack. I hope Luke's suggestion helps (though if I read the commit notes correctly, the chances are very slim in this case). At the same time, I'm glad this bug has been brought up, as it should definitely be backported to 5.2, possibly to 5.1, even. I'm adding backportRequest tags. Andrew, can you cherry-pick your commit to those branches?
(In reply to Aron Budea from comment #22) > I'm sorry to hear about your lost work, Slack. I hope Luke's suggestion > helps (though if I read the commit notes correctly, the chances are very > slim in this case). > > At the same time, I'm glad this bug has been brought up, as it should > definitely be backported to 5.2, possibly to 5.1, even. I'm adding > backportRequest tags. > Andrew, can you cherry-pick your commit to those branches? Thanks for the suggestion Aron - I'm new to the LibreOffice development process, so I wasn't sure if this was something I should initiate. I've submitted two new pull requests for backporting this fix: libreoffice-5-2: https://gerrit.libreoffice.org/#/c/27919/ libreoffice-5-1: https://gerrit.libreoffice.org/#/c/27921/
anwilli5 committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1647335fddabb1e31d6c9a41b3dc2aca31d86a9d&h=libreoffice-5-2 tdf#96607 'Save as' doesn't update global auto-recovery state It will be available in 5.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It seems commit notification was lazy this time, here's the commit in "libreoffice-5-1": https://cgit.freedesktop.org/libreoffice/core/commit/?id=e3759a3154de534a5edfd69f7face5b5c29c1ea9&h=libreoffice-5-1 Thanks Andrew & others!
I just wanted to thank you for finding the root cause of the bug and fixing it. There were several reporters of this bad bug in Fedora, but we hadn't been able to reproduce it consistently.