Bug Hunting Session
Bug 96607 - Auto-save functionality stops working after a 'Save as' operation
Summary: Auto-save functionality stops working after a 'Save as' operation
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: x86-64 (AMD64) Windows (All)
: high major
Assignee: Andrew
URL:
Whiteboard: target:5.3.0 target:5.2.1 target:5.1.6
Keywords: dataLoss
: 95535 95591 95787 99890 (view as bug list)
Depends on:
Blocks: AutoSave-AutoRecovery-Backup
  Show dependency treegraph
 
Reported: 2015-12-20 02:28 UTC by Andrew
Modified: 2016-11-11 11:42 UTC (History)
12 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 Andrew 2015-12-20 02:28:47 UTC
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
Comment 1 Buovjaga 2015-12-23 19:02:48 UTC
(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)
Comment 2 Alex 2016-02-26 08:13:49 UTC
Maybe related with https://bugs.documentfoundation.org/show_bug.cgi?id=95591
?
Comment 3 Buovjaga 2016-06-05 16:14:12 UTC
Andrew: you assigned this to yourself. Are you going to fix the bug?
Comment 4 Andrew 2016-06-05 18:52:04 UTC
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.
Comment 5 Buovjaga 2016-06-05 18:57:51 UTC
(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
Comment 6 Aron Budea 2016-06-06 00:07:22 UTC
*** Bug 99890 has been marked as a duplicate of this bug. ***
Comment 7 Aron Budea 2016-06-10 22:47:12 UTC
*** Bug 95787 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Basler 2016-06-20 19:26:10 UTC
*** Bug 95591 has been marked as a duplicate of this bug. ***
Comment 9 Matthias Basler 2016-06-20 20:25:10 UTC
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.)
Comment 10 Andrew 2016-06-20 21:39:26 UTC
(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.
Comment 11 Matthias Basler 2016-06-21 16:51:45 UTC
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?)
Comment 12 Buovjaga 2016-06-21 17:06:04 UTC
(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.
Comment 13 Kumāra 2016-06-22 01:45:09 UTC
*** Bug 95535 has been marked as a duplicate of this bug. ***
Comment 14 Commit Notification 2016-06-23 10:11:26 UTC
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.
Comment 15 Matthias Basler 2016-06-24 21:57:48 UTC
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.
Comment 16 Buovjaga 2016-06-25 07:32:08 UTC
(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/
Comment 17 Matthias Basler 2016-06-25 07:58:19 UTC
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 ...
Comment 18 Matthias Basler 2016-06-25 08:51:43 UTC
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.
Comment 19 Andrew 2016-07-03 19:00:45 UTC
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.
Comment 20 Slack 2016-07-30 22:13:50 UTC
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?
Comment 21 Luke Kendall 2016-07-30 22:28:27 UTC
(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
Comment 22 Aron Budea 2016-07-30 22:54:57 UTC
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?
Comment 23 Andrew 2016-08-06 04:40:22 UTC
(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/
Comment 24 Commit Notification 2016-08-09 23:14:52 UTC
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.
Comment 25 Aron Budea 2016-08-18 22:42:30 UTC
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!
Comment 26 Milan Bouchet-Valat 2016-11-11 11:42:08 UTC
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.