Download it now!
Bug 95591 - Autosave appears not to be working
Summary: Autosave appears not to be working
Status: RESOLVED DUPLICATE of bug 96607
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: AutoSave-AutoRecovery-Backup
  Show dependency treegraph
Reported: 2015-11-05 05:21 UTC by Luke Kendall
Modified: 2016-06-21 01:01 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Zip file of scree shots of the recovery process (452.55 KB, application/zip)
2015-11-11 02:24 UTC, Luke Kendall
Screenshot of the auto-recovery "completion" dialogue (55.02 KB, image/png)
2016-02-27 04:46 UTC, Luke Kendall

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2015-11-05 05:21:47 UTC
As mentioned in my bug report 95241, Autosave does not save my work.  Every 10 mins it kicks in and I see the save progress bar which makes it look like it's doing something.  But every time LO has locked up on me and I ;va had to kill it, when I restart it has not been able to recover, and instead had to "restore the original docuemnt.

I just tested again: worked for 20 mins, took a screen snapshot so if it does crash now I can recover my work, then waited.  What I see now in the backup area is nothing:

$ ls -lt WildThing-CS.odt
-rw-rw---- 1 luke kendall 5339164 Nov  5 15:28 WildThing-CS.odt
$ ls -la ~/.config/libreoffice/4/user/backup/
total 8
drwxrwx--x  2 luke kendall 4096 Nov  5 15:59 .
drwxrwx--x 14 luke kendall 4096 Nov  5 16:04 ..

The last time LO hung, when I restarted it, tThere were 4 files it needed to recover.  As usual, despite the autosave kicking in at regular intervals, I got errors like this for each of the 4 documents:

/home/luke/.config/libreoffice/4/user/backup/WildThing-CS.odt_0.odt does not exist
(and an error about not having access permissions or something like that).

After the 1st such pop-up error, I did this to see what was in the backup area:

$ ls -la /home/luke/.config/libreoffice/4/user/backup/
total 8
drwxrwx--x  2 luke kendall 4096 Nov  5 11:56 .
drwxrwx--x 14 luke kendall 4096 Nov  5 12:05 ..

Incidentally, at the end of the automatic recovery process, LO presents a confusing summary window.  The dialog panel said:

The automatic recovery process was interrupted. [See Note 1]

The documents listed below will be saved in the folder noted below if you click 'Save'.  Click 'Cancel' to close the wizard without saving the documents.

[the 4 docs listed]
Save to:
etc. [See Note 2]

[Note 1]
It wasn't "interrupted": perhaps it meant to say it didn't complete for some reason; or it encountered some problem?

[Note 2]
a) So, I chose Save, and as I expected from past behaviour, the files had not been *not* saved in /home/luke.
b) In addition, the Save menu item on the File menu was grayed out.  I could choose Save As, and save it back over the top of the existing file, or navigate to /home/luke to save it there if I wished, but that wasn't the default option.
c) I moved the file aside and then saved the recovered document.  It was smaller than the file I moved aside.  I compared the two documents and a dialog panel appeared listing two changes, but when I visited each, I could not see any change (I could see no difference).
Neither document had the work I'd done, but I had taken a screenshot as soon as I realised LO had locked up, so I lost no work.

Of the 4 documents, 3 I was not working on a lot, and had saved, so I had no qualm about choosing to save back over the original document in its original location.  The 4th, which I *was* actively working on, when I chose Save As, again opened the dialog opened on the directory where the original document existed, not /home/luke.

So the panel that pops up after auto recovery seems very unclear to me.  I can't understand in what sense the "files were saved to /home/luke", as that didn't happen; nor was saving the file to /home/luke the default option in any sense.
Comment 1 Luke Kendall 2015-11-07 06:36:27 UTC
If it helps, I just observed the save progress bar on an autosave (at 17:04), and checked - the directory is empty, but strangely, the directory itself was modified:

$ ls -la ~/.config/libreoffice/4/user/backup/
total 8
drwxrwx--x  2 luke kendall 4096 Nov  7 17:04 .
drwxrwx--x 14 luke kendall 4096 Nov  7 17:04 ..

Is that what you would expect?  That path above correctly matches what The LibreOffice>Paths>Backups option is set to.

I have "Save AutoRecovery information" ticked.

I have "Always create backup copy" unticked, because I don't want a backup of the previous version.  I just want to not lose all my work when LO crashes or stops responding.

Oh, I also ran "find ~ -mmin -10 -print", but didn't find any files created anywhere that might be the autorecovery data.  I did notice that the file  ~/.config/libreoffice/4/user/registrymodifications.xcu also had the same modification time, but from viewing it, it seemed to have information unrelated to auto recovery.

I hope the above information helps.
Comment 2 Luke Kendall 2015-11-07 06:51:46 UTC
Oh, I should add that a normal Save takes about 10 seconds; the autosave takes the same length of time.  (Even though there is no file in the backup area afterwards.)
Comment 3 Luke Kendall 2015-11-11 02:24:31 UTC
Created attachment 120471 [details]
Zip file of scree shots of the recovery process

As part of bug 95267 reporting, I had just selected "Format All Comments" and selected 10 point, then saved the file to see whether the format change would be correctly saved.

However, at that point LO crashed.  A panel popped up saying "Due to an unexpected error, LibreOffice crashed.  All the files you were working on will now be saved." etc.

LO did not successfully save the changes, nor did it even appear to notice that the document was open (it was not recovered).  (The file name was WildThing-CS-slow.odt).

I have attached screenshots of representative steps in the recovery process:
Comment 4 -pk- 2015-11-25 16:55:29 UTC
I had a similar experience. After a crash, it said the document recovered in the status bar, however it displayed error prompts and asked me to save it to my documents. No document was saved or recovered. Autosave appears to be not working after manually searching the backup folder.
Comment 5 -pk- 2015-11-29 07:41:22 UTC
I forgot to mention it was on Windows 7.
Comment 6 Luke Kendall 2015-11-29 10:50:04 UTC
FWIW, it happened again today.  I closed a file, and LO (all documents being edited) crashed.  The document recovery process on this occasion, however, recovered all documents except the important one, my novel.

Perhaps because it's longest?  (135k wds, 770k chars, a front cover and back cover image.)  But that said, for me LO more often than not fails to recover any document that's open during the crash, and has to use "recover original". Which means you lose all your unsaved work.
Comment 7 Alex 2016-02-25 12:41:17 UTC
Autosave does not work after you save an opened file.
If you open a file and work with it without saving, autosave function works and backup file is created. If you save file and continue to work with it, backup is deleted, and the new one is not created.
Video -
Sorry I didn't cut the video.
Fresh installation of xubuntu 14.04 with all the updates and LibreOffice 5.0.5 was used.
In 5.1.0 version this problem is not solved either.
Comment 8 Buovjaga 2016-02-26 09:15:20 UTC
Luke: do you think this is the same as bug 96607?
Comment 9 Luke Kendall 2016-02-26 14:46:53 UTC
I've just done a little test, and I don't think so.

On the occasions when I have looked in the backup area, it is usually empty.

I just modified an open file; my auto-recovery backup interval is set to 10 mins.

At that point, the auto-recovery area is empty (not too surprising, since I try to ensure all my files are saved before I stop working).  I currently have 4 open files.

$ ls -la ~/.config/libreoffice/4/user/backup
drwxrwx--x 15 luke kendall 4096 Feb 27 01:24 ..
drwxrwx--x  2 luke kendall 4096 Feb 26 19:38 .

So I waited more than 10 mins, enough time for the auto-recovery to have saved a copy of the modified file.

The file had indeed been created in the backup area.

$ ls -la ~/.config/libreoffice/4/user/backup
drwxrwx--x 15 luke kendall   4096 Feb 27 01:29 ..
drwxrwx--x  2 luke kendall   4096 Feb 27 01:29 .
-rw-------  1 luke kendall 223525 Feb 27 01:29 tweets.odt_0.odt

So the auto-recovery file is there.

I then saved the modified file, and the backup file was removed.

$ ls -la ~/.config/libreoffice/4/user/backup
drwxrwx--x 15 luke kendall 4096 Feb 27 01:32 ..
drwxrwx--x  2 luke kendall 4096 Feb 27 01:32 .

At 1:42 I checked again but this time the backup file was NOT there, although the directory modification time had changed - pretty suspicious!

$ ls -la ~/.config/libreoffice/4/user/backup
drwxrwx--x 15 luke kendall 4096 Feb 27 01:42 ..
drwxrwx--x  2 luke kendall 4096 Feb 27 01:42 .

So the behaviour Andrew is quite similar what I am seeing now with LO on Linux 64 bit.

It's possible that I had not modified the "tweets" file after I had reopened it, until just now for this test.  I.e. maybe my mods to it were the first changes to *that* file since I'd started using LO
Comment 10 Luke Kendall 2016-02-27 04:41:07 UTC
Since my Linux system crashed while reporting this bug, I'm in position to note that as expected, since the backup area was empty, none of the documents were recovered from there.

But I would like to point out (again) that LO does not do what it says it will, after the autorecovery is complete.  I'll attach a screenshot.

It says if I click Save, the files listed will be saved in a directory (in this case, my Home directory).

I clicked Save: the documents were *not* saved there.  As far as I could see, they were not saved anywhere new.

When I clicked Save from one of the (now reopened) document, that too did not save in the directory stated in the autorecovery panel (good), but was saved in the directory where the document "lives" (good).

Could someone please correct the autorecovery-completion dialogue to state what it will really do when you click Save?  See attached screenshot
Comment 11 Luke Kendall 2016-02-27 04:46:27 UTC
Created attachment 123020 [details]
Screenshot of the auto-recovery "completion" dialogue

The promised screenshot showing the text which is wrong.

Note also that even for the single document which it said it had successfully recovered from backup, was not saved into the stated directory either.

None of the documents were actively Saved anywhere.  The previously-saved versions of the documents were all in the places they were supposed to be, and had not been Saved over the top of, based on their modification dates.

The Save in this dialogue appears to be a no-op.
Comment 12 Luke Kendall 2016-03-16 05:42:22 UTC
Just installed LO, along with a bunch of other updates for Ubuntu 16.04LTS (development).
I was re-opening 8 recent documents I'd been working on, and on about the 6th LO just crashed.
But for the first time in about a year, when it restarted, it did in fact recover each of the documents (green tick and all), and proceeded normally.
And I see a file appear in ~/.config/libreoffice/4/user/backup/ 10 mins after I modified a document, and disappear from there after saving, as expected.

But after that 1st save, although I make changes and more than 10 mins pass without me saving again, and I see the auto-save kick in and the save-progress bar, no files appear in the backup area again.

This behaviour is completely consistent for me, has been for many versions, and seems to be a significant problem.  Does that mean that some people are not able to reproduce this behaviour?

Is there some logging I could turn on, to learn more about what's going on when kit appears to take a backup copy, but doesn't?

Because the directory modification time seems to change at 10 min intervals, matching the auto-save times, my guess is that the file is saved and then immediately removed afterwards:

$ ls -la ~/.config/libreoffice/4/user/backup/
total 8
drwxrwx--x  2 luke kendall 4096 Mar 16 16:20 .
drwxrwx--x 15 luke kendall 4096 Mar 16 16:20 ..
$ ls -la ~/.config/libreoffice/4/user/backup/
total 8
drwxrwx--x  2 luke kendall 4096 Mar 16 16:30 .
drwxrwx--x 15 luke kendall 4096 Mar 16 16:30 ..
$ ls -la ~/.config/libreoffice/4/user/backup/
total 8
drwxrwx--x  2 luke kendall 4096 Mar 16 16:41 .
drwxrwx--x 15 luke kendall 4096 Mar 16 16:41 ..

Comment 13 Alex 2016-03-16 06:24:39 UTC
(In reply to Luke Kendall from comment #12)
> Because the directory modification time seems to change at 10 min intervals,
> matching the auto-save times, my guess is that the file is saved and then
> immediately removed afterwards:
That’s exactly how I feel.
View a list of open file descriptors after saving:
cd /proc/2710/fd;ls -la
lr-x------ 1 test test 64 Mar 16 08:57 0 -> /dev/null
lrwx------ 1 test test 64 Mar 16 08:57 24 -> /tmp/lu2710ufo9oo.tmp/lu2710ufo9ow.tmp
lr-x------ 1 test test 64 Mar 16 08:57 9 -> /opt/libreoffice5.1/program/types/offapi.rdb

/tmp/lu2710ufo9oo.tmp/lu2710ufo9ow.tmp  - This is a temporary file
That is, the file is moved to the tmp. And is not restored after crash.
Comment 14 Luke Kendall 2016-03-28 07:04:25 UTC
Aargh!  Just lost an hour's work, since I was so absorbed in composition/writing.  And of course, as usual, autosave, despite interrupting me regularly, had saved Nothing.

I don't understand why this bug is not being addressed.  It LOSES USER DATA.
Comment 15 Luke Kendall 2016-03-28 09:51:42 UTC
Yeah, took me between an hour and a half to two hours to recreate most of what I had before the crash.  (The difference between being in a "flow state", and not.)
Comment 16 Alex 2016-03-28 10:42:15 UTC
(In reply to Luke Kendall from comment #14)
> Aargh!  Just lost an hour's work, since I was so absorbed in
> composition/writing.  And of course, as usual, autosave, despite
> interrupting me regularly, had saved Nothing.
If not reboot after crash, you can find file with autosaved document in tmp with non correct extension.
But is ugly workaround.
Comment 17 Luke Kendall 2016-03-28 11:37:20 UTC
Thanks, Alex.  Ubuntu's apport, when I tried to report the bug, said it couldn't because various packages needed updating.  I ran Synaptic, and 30 mins later all was done, and I restarted just LO, not the whole machine, fortunately.  While waiting, I made notes as best I could and then spent the next hour trying to remember and redo the changes as best I could.

So, thanks for the tip.  Yes, I found the relevant doc and copied it and renamed it, and it does have most of the work.  So I can compare to what I did, "Bare brained", so probably I won't have lost much, except very precious time.

Anyway, thanks for your advice, it will be really useful.

I hope you can persuade someone to increase the priority of attending to this bug, however.

Thanks again.
Comment 18 Matthias Basler 2016-06-20 19:26:10 UTC
Looks like a duplicate of 96607, which is already confirmed and worked on, it seems. Thus I close this one. Feel free to re-open if you disagree.

*** This bug has been marked as a duplicate of bug 96607 ***
Comment 19 Luke Kendall 2016-06-21 01:01:45 UTC
I think it's plausible that this is a duplicate of bug 99607, yes.

But please note the UI error noted in comments 10 and 11 - the text describes actions that LO does not do.  I think the text is wrong: I don't see why LO should offer to save files into your home directory.  That is just likely to lead to user confusion, with conflicting versions of documents.

So I'm glad LO does NOT do what its auto-recovery dialogs say it WILL do!