Download it now!
Bug 65509 - FILESAVE "Automatically save" (Found in Options > LO > Advanced > Expert Configuration ) not running
Summary: FILESAVE "Automatically save" (Found in Options > LO > Advanced > Expert Conf...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError, needsDevEval, topicUI
: 66190 66902 76950 94706 97540 123424 127224 (view as bug list)
Depends on:
Blocks: AutoSave-AutoRecovery-Backup
  Show dependency treegraph
 
Reported: 2013-06-07 14:19 UTC by pierre-yves samyn
Modified: 2020-04-28 14:23 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
ExpertConfig search for AutoSave in 5.0.2.2 (23.22 KB, image/png)
2015-10-05 14:12 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pierre-yves samyn 2013-06-07 14:19:43 UTC
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
Comment 1 m.a.riosv 2013-06-08 11:46:00 UTC
Reproducible
Win7x64Ult.
Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6
Comment 2 Jacques Guilleron 2013-06-09 07:22:52 UTC
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
Comment 3 Jacques Guilleron 2013-07-15 13:27:03 UTC
*** Bug 66902 has been marked as a duplicate of this bug. ***
Comment 4 Leon Arundell 2013-09-01 22:47:21 UTC
*** Bug 66190 has been marked as a duplicate of this bug. ***
Comment 5 Ivo Smelhaus 2014-01-26 22:14:36 UTC
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.
Comment 6 Joel Madero 2015-05-12 18:54:31 UTC
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.
Comment 7 Joel Madero 2015-05-12 19:14:59 UTC
I pushed a patch to hide the option entirely considering it's never worked properly.
Comment 8 pierre-yves samyn 2015-05-13 06:11:45 UTC
(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
Comment 9 m.a.riosv 2015-05-13 12:08:40 UTC
I think not only make it invisible, but also set up to false, to avoid it working from an updated profile.
Comment 10 Commit Notification 2015-05-14 09:28:33 UTC
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.
Comment 11 V Stuart Foote 2015-10-05 14:08:57 UTC
*** Bug 94706 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2015-10-05 14:11:40 UTC
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.
Comment 13 V Stuart Foote 2015-10-05 14:12:52 UTC
Created attachment 119311 [details]
ExpertConfig search for AutoSave in 5.0.2.2
Comment 14 -pk- 2015-11-25 17:02:26 UTC
Autosave doesn't appear to be working for me in 5.0.2.2.
Comment 15 Joel Madero 2015-11-25 17:23:44 UTC
It seems like auto save not working at all is a separate issue from this one. Should be reported separately. Thanks
Comment 16 Robinson Tryon (qubit) 2015-12-10 10:22:38 UTC Comment hidden (obsolete)
Comment 17 Harald Koester 2016-01-04 14:25:37 UTC
*** Bug 76950 has been marked as a duplicate of this bug. ***
Comment 18 Harald Koester 2016-01-04 14:40:33 UTC
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.
Comment 19 Buovjaga 2016-02-07 19:51:17 UTC
*** Bug 97540 has been marked as a duplicate of this bug. ***
Comment 20 christian 2016-02-19 08:17:23 UTC
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!
Comment 21 Yousuf Philips (jay) (retired) 2016-03-09 02:16:39 UTC
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.
Comment 22 Cor Nouws 2016-03-15 16:10:07 UTC
> 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.. )
Comment 23 Cor Nouws 2016-03-15 16:15:12 UTC
(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?)
Comment 24 Patrick Smits 2016-03-18 11:41:26 UTC
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?
Comment 25 Cor Nouws 2016-03-18 13:32:25 UTC
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
Comment 26 Yousuf Philips (jay) (retired) 2016-03-19 14:33:52 UTC
(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.
Comment 27 Harald Koester 2016-03-22 15:18:01 UTC
(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.
Comment 28 rob 2016-03-31 20:15:41 UTC
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?
Comment 29 QA Administrators 2018-09-23 02:50:06 UTC Comment hidden (obsolete)
Comment 30 Cor Nouws 2018-09-23 07:30:11 UTC
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
Comment 31 Cor Nouws 2018-09-23 07:33:12 UTC
as per comment: "this never worked correctly" and duplicate in 3.5.x > old bug.
Comment 32 Cor Nouws 2018-09-23 07:40:19 UTC
sorry, I'm confused about earlier versions, when it was implemented. Setting version to unspecified.
Comment 33 Harald Koester 2018-09-25 10:46:33 UTC
--- 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”.
Comment 34 Jean-Baptiste Faure 2019-02-17 16:29:47 UTC
*** Bug 123424 has been marked as a duplicate of this bug. ***
Comment 35 Joe Abraham 2019-12-29 10:14:11 UTC
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.
Comment 36 Joe Abraham 2020-01-22 06:40:22 UTC
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.
Comment 37 Buovjaga 2020-04-28 14:23:28 UTC
*** Bug 127224 has been marked as a duplicate of this bug. ***