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. Documents: [the 4 docs listed] Save to: /home/luke 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.
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.
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.)
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: LO-comment-save-crash-screenshots.zip
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.
I forgot to mention it was on Windows 7.
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.
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 - https://www.youtube.com/watch?v=BxsJt0M1LBA 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.
Luke: do you think this is the same as bug 96607?
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 5.1.0.3 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 5.1.0.3.
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
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.
Just installed LO 5.1.1.2, 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 .. HTH.
(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: Hi! 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.
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.
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.)
(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.
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.
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 ***
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!