I expect auto-save to happen at the intervals I have set in the Options, and to be measured starting from the time of the last save, *especially including* the time I last manually saved. Instead, auto save seems to occur on a fixed interval. I just double-checked this: I saved my document (waited 15 seconds for it to complete), then continued editing. Within 15 seconds, the regular auto-save once again interrupted my work and occurred. (I have set the period to 20 mins). I believe the idea of auto save is to preserve your work, in case of a crash, power failure, or similar. The purpose of setting a time period is to limit the amount of work that might be lost. For a long document, auto save takes long enough to end a 'flow state', and is somewhat disruptive. Having it kick in to save a few seconds of work is intensely annoying. It also means a user cannot avoid auto-save even by being so disciplined that they manually save more frequently than the auto save period they have chosen. With the current method of setting the start time for the time measurement, the auto-save feature is almost annoying enough for me to turn it off and just rely on remembering to manually save, myself. Please consider changing this behaviour.
it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I've upgraded to 5.2.5.1, the freshest available at that URL. I think you're quite right, and this has been resolved. This should I think be moved to Resolved, so I'll try to mark this report as such (rather tahn UNCONFIRMED).
No, it's not properly fixed: I just had it happen to me again right now. I have multiple files opened. In my main one, I accidentally held down the Ctrl key instead of the Shift key when I typed "She", and of course saved the file and the letters "he" appeared. I continued editing the main document, and approx. 30 seconds after my Save, the auto-save kicked in again. A 2nd document I had open then performed its auto-save. I have the period set to 15 mins. Is it possible LO gets confused about which documents need auto-saving? Or saves all changed docs if any one needs an auto-save? The auto-save start time is per document, isn't it? Anyway, it was very clear: 30 secs after manually saving, auto-save kicked in again. This is with 5.2.5.1.
Hmm. Just experienced another auto-save, less than 2 mins after another manual save of the doc. But it was also less than 5 mins since the 2nd doc I'm working on auto-saved (maybe, 3 mins). So I can't see any pattern to it. Auto-save interval is set to 15 mins.
Saved at 16:11. Kept working. Auto-save kicked in at 16:12. And manually saved at 16:26; auto-save kicked in anyway, at 16:28. 16:43: secondary document auto-saved. Then I manually saved the main doc (also at 16:43, maybe 10 seconds later), checked that, then made a small change. And at 16:44, the main doc auto-saved again. It's definitely not fixed.
From my experiments, I can see each doc has its own individual time at which it gets auto-saved. The secondary doc was auto-saving a minute before the main doc. Saving the secondary document (so it needed no auto-save) did not prevent the auto-save of another working document. (I.e., the events are independent, as they should be.) Nor did saving the main doc within that one minute gap prevent its auto-save: I made a small edit of the main doc, and within 30 seconds of my manual save, the auto-save triggered on the main doc. It's very strange I could not reproduce this behaviour when I started using 5.2.5.1, and thought it was fixed. One very odd thing: the times and sizes don't match what I expected. My main doc is called ShadowHunt-CS.odt; it's 590069 bytes. Secondary doc is ShadowHunt-CS-Q3,thEditors.odt: 171721 bytes. So: small doc is the secondary, large file is the primary. But I noted the time the secondary file was saved (18:15), and when the larger primary file was auto-saved (a minute later, at 18:16). Yet the file size+time pair is the reverse of what I would expect in /tmp: In /tmp, I see: /tmp/lu4682tv3ttn.tmp -rw-r----- 1 luke kendall 171721 Feb 12 18:16 lu4682tv3vcw.tmp -rw-r----- 1 luke kendall 590069 Feb 12 18:15 lu4682tv3vcp.tmp It says the small doc was saved at 18:16, the larger one at 18:15. This is the reverse of what I observed. Is it possible that LO thinks it's auto-saving one file, when it's saving the other? Oh, and another strange thing: while writing this comment, I just noted that an auto-save occurred on the main doc, ShadowHunt-CS.odt, at 18:31. But in the /tmp directory, the file timestamps are unchanged (although the directory is now 18:31). Does LO write the file, compare if it's the same as the previous one, then remove the just-written file if they're the same?! Why bother comparing? Why wouldn't you just remove the older auto-save instead of the most recent one? In /tmp, at 18:38: drwx------ 2 luke kendall 4096 Feb 12 18:31 lu4682tv3ttn.tmp In /tmp/lu4682tv3ttn: -rw-r----- 1 luke kendall 171721 Feb 12 18:16 lu4682tv3vcw.tmp -rw-r----- 1 luke kendall 590069 Feb 12 18:15 lu4682tv3vcp.tmp I can't make sense of the timing": it looks wrong. I just noticed I hadn't saved for a while, though making lots of changes. The file was: -rw-rw---- 1 luke kendall 590176 Feb 12 19:21 ShadowHunt-CS.odt In /tmp: -rw-r----- 1 luke kendall 590176 Feb 12 19:21 lu4682tv3ved.tmp This was at 19:46: *more* than 15 mins since the last manual save (19:21). At 19:48 I manually saved again: -rw-rw---- 1 luke kendall 589972 Feb 12 19:48 ShadowHunt-CS.odt and afterward, found that the /tmp copy was the same size+time: -rw-r----- 1 luke kendall 589972 Feb 12 19:48 lu4682tv3vf1.tmp Yeah, I did the same manual save at 19:57, and the same thing happened: -rw-rw---- 1 luke kendall 589987 Feb 12 19:57 ShadowHunt-CS.odt -rw-r----- 1 luke kendall 589987 Feb 12 19:57 lu4682tv3vf8.tmp Yes: the time is now 20:28, last save was 20:10, I've been making changes, but it's not been auto-saved for over 17 mins, even though auto-save interval is set to 15 mins: -rw-r----- 1 luke kendall 590106 Feb 12 20:10 lu4682tv3vfm.tmp -rw-rw---- 1 luke kendall 590106 Feb 12 20:10 ShadowHunt-CS.odt Or now, at 20:32: -rw-r----- 1 luke kendall 590106 Feb 12 20:10 lu4682tv3vfm.tmp I can't make sense of this, but it's certainly not operating when it's supposed to. No wonder I've lost more work than I expected, when LO crashed.
Maybe also an interaction with the LO bug that loses files saved (so that it complains it can't find the recovery files after a crash). I noticed these files in /tmp after auto-save of my secondary document had finished: $ ls -lt /tmp/lu4682tv3ttn.tmp | head -rw------- 1 luke kendall 602112 Feb 12 21:04 lu4682tv3vhx.tmp -rw------- 1 luke kendall 601950 Feb 12 21:04 lu4682tv3vhw.tmp -rw------- 1 luke kendall 0 Feb 12 21:04 lu4682tv3vhu.tmp -rw------- 1 luke kendall 57022 Feb 12 21:04 lu4682tv3vhq.tmp -rw------- 1 luke kendall 60064 Feb 12 21:04 lu4682tv3vhn.tmp -rw------- 1 luke kendall 54522 Feb 12 21:04 lu4682tv3vhk.tmp -rw------- 1 luke kendall 44070 Feb 12 21:04 lu4682tv3vhh.tmp -rw------- 1 luke kendall 38679 Feb 12 21:04 lu4682tv3vhe.tmp -rw------- 1 luke kendall 33494 Feb 12 21:04 lu4682tv3vhb.tmp -rw------- 1 luke kendall 113117 Feb 12 21:04 lu4682tv3vh8.tmp -rw------- 1 luke kendall 65612 Feb 12 21:04 lu4682tv3vh5.tmp -rw-r----- 1 luke kendall 540149 Feb 12 20:49 lu4682tv3vgt.tmp -rw-r----- 1 luke kendall 590187 Feb 12 20:34 lu4682tv3vg0.tmp And this, about 30 secs later, after auto-save of the main document had happened. Note that the two largest and newest auto-save files are gone: $ ls -lt /tmp/lu4682tv3ttn.tmp | head -rw------- 1 luke kendall 57022 Feb 12 21:04 lu4682tv3vhq.tmp -rw------- 1 luke kendall 60064 Feb 12 21:04 lu4682tv3vhn.tmp -rw------- 1 luke kendall 54522 Feb 12 21:04 lu4682tv3vhk.tmp -rw------- 1 luke kendall 44070 Feb 12 21:04 lu4682tv3vhh.tmp -rw------- 1 luke kendall 38679 Feb 12 21:04 lu4682tv3vhe.tmp -rw------- 1 luke kendall 33494 Feb 12 21:04 lu4682tv3vhb.tmp -rw------- 1 luke kendall 113117 Feb 12 21:04 lu4682tv3vh8.tmp -rw------- 1 luke kendall 65612 Feb 12 21:04 lu4682tv3vh5.tmp -rw-r----- 1 luke kendall 540149 Feb 12 20:49 lu4682tv3vgt.tmp -rw-r----- 1 luke kendall 590187 Feb 12 20:34 lu4682tv3vg0.tmp -rw-r----- 1 luke kendall 170335 Feb 12 20:11 lu4682tv3vft.tmp -rw-r----- 1 luke kendall 44258 Feb 12 19:28 lu4682tv3vei.tmp -rw-r----- 1 luke kendall 37055 Feb 11 22:56 lu4682tv3v5q.tmp Note also that the time and size of the 20:34 file matches that of the main doc, last saved: -rw-rw---- 1 luke kendall 590187 Feb 12 20:34 ShadowHunt-CS.odt, and that whatever the auto-saved file 15mins later (at 20:49) is, it's too small to be a backup copy of the main doc. And after saving the main doc, manually, after the auto-save: -rw-rw---- 1 luke kendall 590776 Feb 12 21:11 ShadowHunt-CS.odt And in /tmp, after that manual save: $ ls -lt /tmp/lu4682tv3ttn.tmp | head -rw-r----- 1 luke kendall 590776 Feb 12 21:11 lu4682tv3vic.tmp -rw------- 1 luke kendall 57022 Feb 12 21:04 lu4682tv3vhq.tmp -rw------- 1 luke kendall 60064 Feb 12 21:04 lu4682tv3vhn.tmp -rw------- 1 luke kendall 54522 Feb 12 21:04 lu4682tv3vhk.tmp -rw------- 1 luke kendall 44070 Feb 12 21:04 lu4682tv3vhh.tmp -rw------- 1 luke kendall 38679 Feb 12 21:04 lu4682tv3vhe.tmp -rw------- 1 luke kendall 33494 Feb 12 21:04 lu4682tv3vhb.tmp -rw------- 1 luke kendall 113117 Feb 12 21:04 lu4682tv3vh8.tmp -rw------- 1 luke kendall 65612 Feb 12 21:04 lu4682tv3vh5.tmp -rw-r----- 1 luke kendall 540149 Feb 12 20:49 lu4682tv3vgt.tmp -rw-r----- 1 luke kendall 170335 Feb 12 20:11 lu4682tv3vft.tmp -rw-r----- 1 luke kendall 44258 Feb 12 19:28 lu4682tv3vei.tmp -rw-r----- 1 luke kendall 37055 Feb 11 22:56 lu4682tv3v5q.tmp I hope this information is helpful.
LO just crashed on me at 17:25. Last time I manually saved was 16:52. Last date on auto save is the same, 16:52. So I will have lost data because this function simply does not perform as it is supposed to. Surely that makes this bug more serious, and it should have a higher priority to fix: it can lead to data loss when LO crashes. Yeah, just restarted LO and confirmed that I have lost 30 mins of intense work. Very disappointed.
Yeah, this bug is probably Writer's most irritating behaviour at the moment. It feels like it's constantly interrupting my work, which is intensely frustrating to be interrupted for 20-30secs for each (long) document you have open, when you're in a flow state. It's disruptive enough for me to take the time, mid-work, to add this note.
I updated to 5.2.6.2 today. It's still happening. It's also very clear that Writer does not reset the "last-saved" time to be thew time of your last manual save. Auto-save happens at its regular intervals, even if that's only ten or twenty seconds since you last saved. You can't stave them off by saving manually. It's really annoying and wastes time, on long documents (that take ten seconds or more to save). It's long enough to ruin your "flow state".
This bug was never confirmed. Moving back to UNCONFIRMED
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180102
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20180129