Hello Platform: Windows 7 64bits Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6 I did not select the version because not included in the list at this time. Steps to reproduce 1. Check Tools> Options> Load/Save> General> Save AutoRecovery information every 1minutes (or another short delay) 2. Check Automatically save the document too 3. Open a document and edit it 4. File> New> Text 5. Type something (test for example) 6. Wait for the autoRecovery save. when the specified time has elapsed, AutoRecovery is executed but modified documents are not saved and Save Icon (standard toolbar) and Modified status (status bar) still enabled. Regards Pierre-Yves
Reproducible Win7x64Ult. Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6
Hello Pierre-Yves, I get the save with modified document on master LO 4.2.0.0.alpha0+ Build ID: 3e6853ae3e093b919ff3732e8fac05cb0a0fba5 & Windows 7 Home Premium. Jacques Guileron
*** Bug 66902 has been marked as a duplicate of this bug. ***
*** Bug 66190 has been marked as a duplicate of this bug. ***
In my case LO 4.2.0.2 Kubuntu 13.10 amd64 Even if autorecovery 5 min, automatically save doc. too, always create backup - after 120 min there is just only the latest manually saved version a version saved manually before 1. This situation tend to make user who belies in LO quiet but leaving him in danger of big disaster. That's why I increase the classification to critical (I tend to feel it as blocker, but) 2. In combination with "always create backup copy" which makes the user fell even more secure actually does opposite. Every manually save means loose the previous backup. 3. In combination with strange autorecovery behaviour, when after autorecovery the user get even older version, than the last manually saved makes LO almost unusable for serious work. (I'm not sure, if this is a separate bug or not - if yes, I can create it) From my point of view, the autorecovery function in broader point of view or "user work securing functionality" should be change/fix as complex. The user should be at least before agreeing with autorecovery, provided with information what is he/she doing, i.e. what autorecovery and backup (at least here should be a link to backup file) is here at disposal. Otherwise the user multiply the range of disaster.
My findings: This was never implemented right - it's not a regression, simply bad implementation somewhere in the 4.1 series. As for the priority - I'm changing it for a couple reasons: 1) Clearly not affecting a ton of people, a couple dupes over two years; 2) You're not going to lose any data unless you specifically say "no" to saving when you try to close - if LibrOffice crashes, your auto recovery works fine 3) This was a *new* feature in 4.1 - worst case we should just remove it as it never worked right (something I'll probably do just to avoid confusion) That being said: Major - can result in loss of data if a user deliberately chooses not to save manually when the save prompt comes on; High - default for major issues, seems appropriate.
I pushed a patch to hide the option entirely considering it's never worked properly.
(In reply to Joel Madero from comment #7) > I pushed a patch to hide the option entirely considering it's never worked > properly. Ok, thank you Joel. Therefore, can we close this bug? Regards Pierre-Yves
I think not only make it invisible, but also set up to false, to avoid it working from an updated profile.
Joel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4653c91a89cfe802754377bcdafc291526254a03 tdf#65509 - Auto Save Also Too Disabled It will be available in 5.0.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.
*** Bug 94706 has been marked as a duplicate of this bug. ***
Have another aspect to this in that while suppressed from .UI as in comment 10, it remains available from Expert Configuration where a search for AutoSave returns confusing options.
Created attachment 119311 [details] ExpertConfig search for AutoSave in 5.0.2.2
Autosave doesn't appear to be working for me in 5.0.2.2.
It seems like auto save not working at all is a separate issue from this one. Should be reported separately. Thanks
Migrating Whiteboard tags to Keywords: (implementationError)
*** Bug 76950 has been marked as a duplicate of this bug. ***
In bug 76950 I described the same bug. To my opinion the option works but you have to close and restart again LibreOffice after changing the option. But the question still is: Shall the current solution (hide option) be maintained or shall the bug fixed sometimes in future? In the first case this bug should be closed.
*** Bug 97540 has been marked as a duplicate of this bug. ***
I just realised that the feature is missing. This cost me some data, sadly, because the "normal" AutoRecovery didn't work after a blue screen produced by windows... The AutoRecovery-Program told me that the data couldn't be found. I would prefer that the option to save the document will be implemented again. Now I use the ExpertConfig-settings. By the way - thank you for working on this really fine piece of software!
This should likely be an easy fix as all that is needed is to check whether the checkbox is enabled and if so, execute the .uno:Save command.
> In bug 76950 I described the same bug. To my opinion the option works but > you have to close and restart again LibreOffice after changing the option. So that is a different issue - anyway now that this issue evolved in changing the UI position of AutoSave. IMO reopening bug 76950 is a good thing. (The topic that a restart is needed comes up more frequent. When changing a the language for UI, a message is shown. For changing OpenGL option, the UI shows it in the dialog.. )
(In reply to V Stuart Foote from comment #13) > Created attachment 119311 [details] > ExpertConfig search for AutoSave in 5.0.2.2 When was that changed/implemented? (And did that change turn it on by default?)
I just had a colleague loosing his work. He had created a document and started working in it. He never saved it in between. When he was typing he used some keyboard shortcuts and inadvertently closed the document. He's not sure what exactly happened, since it all went really fast. However the end result was that it did not get stored on disk. I'm not sure if there is solution for these kind of stupidities, but I think it happens quite often in real life situations. It happens to me once or twice a year, although I know I should always start a new document and save it immediately *and* use CTRL-S to save on a regular interval. However the end result is that I don't trust my text editing program from saving me from these kind of stupidities. This probably needs to end up in some kind of feature request, but I really wanted to share it in this bug, so brighter minds can think about a solution that works for users. Maybe always keep a copy of the last 10 documents in a temp directory or something? And save them in 10 minute intervals even when a user says not to save?
Hi Patrick, (In reply to Patrick Smits from comment #24) > I'm not sure if there is solution for these kind of stupidities, .... Yes, do it often enough so that you do it less in the future ;) (Helps for me anyway...) > twice a year, although I know I should always start a new document and save > it immediately *and* use CTRL-S to save on a regular interval. However the Once saved once, autoRecovery works pretty well. If not, it's a gamble. > This probably needs to end up in some kind of feature request, but I really > wanted to share it in this bug,... Better to bring it to a new report (if not covered by an existing one) and assign to libreoffice-ux-advise@lists.freedesktop.org, Thanks, Cor
(In reply to Patrick Smits from comment #24) > I just had a colleague loosing his work. He had created a document and > started working in it. He never saved it in between. When he was typing he > used some keyboard shortcuts and inadvertently closed the document. He's not > sure what exactly happened, since it all went really fast. However the end > result was that it did not get stored on disk. Yes that is unfortunate. > I'm not sure if there is solution for these kind of stupidities, but I think > it happens quite often in real life situations. It happens to me once or > twice a year, although I know I should always start a new document and save > it immediately *and* use CTRL-S to save on a regular interval. However the > end result is that I don't trust my text editing program from saving me from > these kind of stupidities. Yes a solution would be to keep copies of autorecovery saved documents, even when a user has stated not to save it. This was mentioned in bug 94042.
(In reply to Cor Nouws from comment #22) > > In bug 76950 I described the same bug. To my opinion the option works but > > you have to close and restart again LibreOffice after changing the option. > > So that is a different issue - anyway now that this issue evolved in > changing the UI position of AutoSave. > IMO reopening bug 76950 is a good thing. > Sorry Cor, I don't agree in this case. If you go on the test procedure of the original description with: 6. .. 7. Close LibreOffice without saving both files. 8. Restart LibreOffice. 9. Open the document of step 3 and edit it 10. File> New> Text 11. Type something (test for example) 12. Wait for the autoRecovery save. 13. Check the time stamp of the opened document. It has been changed. Hence now autorecovery works correctly at least for existing documents. But it does not work with new documents. I did not found a saved version of the new file, neither in the 'My Documents' folder, nor in the Backup folder and also not in the folder of the already existing document. Tested with version 4.4.7 and Win7.
This is still broken for me on version 4.3.3.2 in debian and version 4.3.7.2 in windows. I have lost half a days work MULTIPLE TIMES. I'm not sure if this report is saying now that it's been fixed or if the autosave feature has been REMOVED? I'm wondering if i'll gain anything by upgrading to the latest version--since I cannot reliably reproduce the bug, the only way to confirm is to see if I lose more swathes of work. I uploaded a question to stackexchange on it since I thought it was a user error at first. http://tinyurl.com/huogel3 As you can see, it sometimes does observe the autosave settings, and sometimes doesn't. I do not know what the conditions are, but right now I have an instance of libreoffice calc open and I type in changes and hit enter, and nothing in the main or backup directory gets updated within the configured timeframe. Earlier today when I did the same test, it updated just fine! > As for the priority - I'm changing it for a couple reasons: > 1) Clearly not affecting a ton of people, a couple dupes over two years; A serious bug felt by one or two people is still a serious bug. I also don't think this is a reliable indicator of how many people are running into it. That assumes the people who experience it are all filing reports. > 2) You're not going to lose any data unless you specifically say "no" to saving when you try to close - if LibrOffice crashes, your auto recovery works fine Who said auto recovery works fine? The autosaves aren't happening which means the backups to the backup directory aren't being saved to recover from it (that's where autorecovery gets it, right?). And I've lost tons of progress after autorecovery. I don't even understand how autorecovery works--even if I try to cancel my way past it it offers to save a backup. It's not intuitive. Not to mention, on multiple occasions the app hasn't closed cleanly. My PC never crashes yet the amount of times I've seen autorecovery pop up is ridiculous. > 3) This was a *new* feature in 4.1 - worst case we should just remove it as it never worked right (something I'll probably do just to avoid confusion) Just to clarify, you're proposing to remove an elementary feature like autosaving of documents that most people would naturally assume to exist in any modern office application?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still not working in Version: 6.2.0.0.alpha0+ Build ID: 3208fcb3a36d75d6290d9c548430682f153b09db CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-20_23:54:32 Locale: nl-NL (nl_NL.UTF-8); Calc: threaded
as per comment: "this never worked correctly" and duplicate in 3.5.x > old bug.
sorry, I'm confused about earlier versions, when it was implemented. Setting version to unspecified.
--- Summary of this bug report --- The option “Automatically save the document too” was introduced in version 4.1.0 and was hidden in version 5.0.0 (see comment 10). Option is still available with the Expert Configuration. Function according to help (version 6.1.x): Specifies that LibreOffice saves all open documents when saving auto recovery information. Uses the same time interval as AutoRecovery does. Additional information: If both options “Always create backup copy” and “Automatically save the document too” are enabled, also the backup copy is updated with the current version of the document in the user defined interval. A backup of the state, when a document has been opened, does not exist in this case. There are 2 cases, where the option “Automatically save the document too” is useful: [1] If LibreOffice crashes and afterwards a recovery is not performed or is not successful. In this case you can just open the respective document and will get the document in the state at the time of the last automatic save. [2] If a user accidentally closes a changed document without saving. Also in this case you get the document in the state at the time of the last automatic save. But the option “Automatically save the document too” does not work as expected in some cases: (1) After enabling the option “Automatically save the document too” LibreOffice has to be closed and restarted again thereby the option becomes effective (see comment 1 and comment 27). (2) New documents that have not been saved by the user at least once, are not saved automatically (see comment 27). (3) According bug 66902 (comment 3) with Linux LibreOffice crashes if the option is enabled. These problems should be fixed, before the option becomes visible again. And a proposal, that should be considered during fixing this bug: The option “Automatically save the document too” only works if the option “Save AutoRecovery information“ is enabled. For a user I think it would be more understandable if both options can be changed independently. In this case you need an additional time interval for the option “Automatically save the document too”.
*** Bug 123424 has been marked as a duplicate of this bug. ***
I'm one of the 'tiny number' of people who have reported this problem. I can't follow all of the comments here, but it seems there are voices calling for hiding it rather than fixing it. If so, let me weigh in. I discovered OpenSource software a couple of decades ago, and have become an avid advocate and implementer, in my life, my blogging, my research, my book writing, my professional work, and my civic activism. I am working on a book talking about how important and revolutionary OpenSource is, and (I hope) pointing the way for some critical contributions the community could make. But OpenSource, like any software, isn't perfect. My machine and various software crash from time to time; there are websites and files that won't work in OpenSource platforms; updates, fixes, and improvements often aren't easy; add-ons that I have become dependent upon aren't updated, and I lose important functionality when I upgrade. Nevertheless, I stay with you guys and gals because I am convinced that your work is essential (and not to wade into politics, but this is particularly true now, with kleptoplutocrats grabbing control everywhere). However, when I'm working and my stuff crashes, and autosave isn't effective, I'm totally screwed. Hours of work disappear. The one poster is right: perhaps only a few people are complaining, but that's an inadequate metric. "96% of unhappy customers don’t complain, however 91% of those will simply leave and never come back." https://beyondphilosophy.com/15-statistics-that-should-change-the-business-world-but-havent/ There are problems with all software. But I have never spent as much time complaining as I am now, because for me, systems that crash without an autosave aren't annoying. They're toxic. And to my mind, ignoring such a large problem contradicts the culture and commitment of OpenSource.
OK, it happened again. Because there is no resolution for this problem, I have been automatically hitting Save on a regular base. But, as sure as God made little green apples, the very first time I am tired and I forget to do it regularly, the system crashes. It happened this morning, lost a good half-hour of work. You cannot be proud of this. And FWIW, I initially submitted this bug with another problem I am having with Copy & Past. The two were separated. You may wish to consider them together, because this AM the system crashed when C&P acted weirdly and I tried to correct it. I can't be sure, but these seem to have happened in tandem before. Problem: I copy, paste and one of two things frequently happens: 1) The *previous* copy (the one before the current one) is pasted instead, and the most recent Copy -- or sometimes Cut -- is gone. Fortunately, I can recover with Ctrl Z. 2) I go to paste, often Ctrl Shift P for an unformatted text paste, and the system pastes a .bmp, and 'unformatted text' simply isn't available in the options. That's what happened this time; when I went to correct the .bmp, the system crashed.
*** Bug 127224 has been marked as a duplicate of this bug. ***
(In reply to Harald Koester from comment #33) > --- Summary of this bug report --- > > The option “Automatically save the document too” was introduced in version > 4.1.0 and was hidden in version 5.0.0 (see comment 10). Option is still > available with the Expert Configuration. Can't find that option. I've searched in expert configuration and with enabling experimental features.
(In reply to Dieter from comment #38) > Can't find that option. I've searched in expert configuration and with > enabling experimental features. It should be there as shown in attachment 119311 [details].
(In reply to Aron Budea from comment #39) > (In reply to Dieter from comment #38) > > Can't find that option. I've searched in expert configuration and with > > enabling experimental features. > It should be there as shown in attachment 119311 [details]. Thank you. It works.
Explaining the meaning of attachment 119311 [details] ExpertConfig search for AutoSave AutoSave: corresponds to Options - Load/Save - Save Autorecovery information AutoSaveTimeInterval: every x minutes AutoSavePrompt - ??? UserAutoSaveEnabled: corresponds to Options - Load/Save - Automatically save the document too. (visible False - see commit 10 patch). In the current implementation, "user auto save" is completely dependent on "recovery auto save". Separating the two would not be easy. (Things like impress slide-show temporarily disable autosave/autorecovery, and things like --headless need to prevent both altogether. > (1) After enabling the option “Automatically save the document too” > LibreOffice has to be closed and restarted again A dialog warns about this now, so not a big deal. > (2) New documents that have not been saved by the user at least once, > are not saved automatically Not surprising. What name would you give it? Where would you save it? I guess that is where it would need to pop up a save-as dialog. But this entire thing seems SUPER FRAGILE. In debugging this, I frequently had to delete the user profile in order to have the autorecovery subsystem start up at all. After two or three option modifications, it would be messed up somehow.