I confirm it's disabled by default
Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 52c75986adc2b370eb55ce918ab1db0a95831c83
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

I assume this being fall-out of a change related to AutoRecovery like bug 149401 or bug 149178, not a UX decision.

The option AuoSave in officecfg/registry/schema/org/openoffice/Office/Common.xcs was set to false at least for 21 years. Mike K and me think there is no harm in changing the default.

See also bug 47988 (resolved INS) and bug 94042 (interval set to 10mins - fixed).

Also, I noticed that "Always create backup copy" is set as false. I set this as true, also, like in the previous versions.

The patch is in gerrit
https://gerrit.libreoffice.org/c/core/+/144020

(In reply to Heiko Tietze from comment #2)
> The option AuoSave in
> officecfg/registry/schema/org/openoffice/Office/Common.xcs was set to false
> at least for 21 years. Mike K and me think there is no harm in changing the
> default.

The pitfall will likely be larger Writer Documents and Calc Spreadsheets. Even worse with multiple of those documents open. LibreOffice will "constantly" (exaggeration) freeze, making the whole suite unusable. Saving large files can take up to 90 seconds and blocks everything

There where (are?) complains about key input lost, typed just before autosave kicked in.. (Writer) And with say 5 documents open at the same time, which AutoSave independently, this might pretty likely to happen.

Note: I'm in favor of AutoSave as such, but autosave sadly isn't something done silently in the background. So this will likely only replace problem A for B..

I guess that the current state being the best there is at this point in time. 

Nothing against a small experiment, though..

First of all, thanks everybody for this open discussion, this is highly appreciated!

> The pitfall will likely be larger Writer Documents and Calc Spreadsheets.

I totally see the possible downsides, so let's play it trough:

AutoSave default is off:
- (New) User creates something 
- App crashes
- Progress is lost
- Negative impression, because AutoSave is off

AutoSave default is on:
- Experienced user who creates bigger documents (and/or many of them) runs into AutoSave issues (too long saving time, other bugs, etc.)
- User deactivates AutoSave or sets interval higher 
- no harm done

(In reply to Nikolai Wüstemann from comment #7)
> First of all, thanks everybody for this open discussion, this is highly
> appreciated!
> 
> > The pitfall will likely be larger Writer Documents and Calc Spreadsheets.
> 
> I totally see the possible downsides, so let's play it trough:
> 
> AutoSave default is off:
> - (New) User creates something 
> - App crashes
> - Progress is lost
> - Negative impression, because AutoSave is off

LibreOffice often the tries to save the file at the point of the crash (with or without AutoSave), not too reliable I admit..

AutoSave does improve things, but in worse case, with the default of 10 min, still lots of work lost :-(
 
> 
> AutoSave default is on:
> - Experienced user who creates bigger documents (and/or many of them) runs
> into AutoSave issues (too long saving time, other bugs, etc.)
> - User deactivates AutoSave or sets interval higher 
> - no harm done

I do agree with the logic in principle. However, the size of the document doesn't really say much about the expertise of the user :-(. The auto-save will come as a surprise in many cases.. and the are not againt an autosave either I guess, core problem: LibreOffice hangs/freezes

A freezing LibreOffice is more obvious than the lost data at a crash. Assuming LibreOffice not crashing regularly.. I expect more complains, compared to the lost data group.

Predicting what will happen is tricky...  So I might be wrong

---
Out of curiosity, what will happen if people upgrade to a new version with autosave enabled by default and a pre-existing profile. Will the default be changed?

*** Bug 152497 has been marked as a duplicate of this bug. ***

I believe the file to look at is framework/source/services/autorecovery.cxx.

So we have enum class Job with types AutoSave, EmergencySave, UserAutoSave (the backup copy).

IIUC, the emergency save is kicked off by an application crash. If it can do so, it attempts an ODT emergency dump. I often see this on my user's computers - where on startup it asks them to recovery a crashed document. This is turned on by default (perhaps it can be disabled with RecoveryInfo - Enabled?). As Nikolai has noticed, this cannot be relied on to ALWAYS provide a recoverable document after a crash.

A timed AutoSave should solve that problem, although I agree with Telesto's assessment that likely there will be loud complaints about this because it will definitely have some rather nasty side effects (since it hasn't been widely tested while being on). So the programmer who turns this on by default should be prepared to spend time fixing regressions that arise. I would definitely suggest to avoid backport this to 7.5. (The one good news item about this is that Collabora Online does UserAutoSave frequently, so hopefully they have already fixed a lot of bugs related to it.)

UserAutoSave is the really dangerous one, which does timed saves on the working document. A problem here could not only lose the work for this session, but it could lose the entire document. This should probably never be enabled without also storing a backup copy.

Bug 65509 suggests that AutoSave is somewhat unreliable... So while the task itself might be EasyHack, the implications will prove challenging.

[Of course I could be completely wrong about all of this. The two days I spent working in this area left me rather confused.]

ESC approve changing the default.

(In reply to Justin L from comment #10)
> I would definitely suggest to avoid backport this to 7.5.

Agreed

Bogdan B committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5cb7fed2a5a02ff1cb4551752a0bd8d3001a1f22

tdf#152463 Turn on AutoSave and Backup by default

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Heiko Tietze from comment #11)
> ESC approve changing the default.

  -> + [Bug 152463] AutoRecovery should be turned on by default
       + default will be true for AutoSave and CreateBackup
https://lists.freedesktop.org/archives/libreoffice/2022-December/089716.html

To explain the reason why I don't like the idea of automatically turning on backup copies: I have worked with a lot of users who simply don't have a good grasp of file management or version control. If there are multiple copies of the same file in the same folder they will easily get confused.

A computer system MUST be setup with a general, versioned, backup system anyway. That is the most appropriate place to store versioned files. Therefore, it is better for LO to default to keeping the document folder clean, leaving it optional for a user to decide to only/supplementally use the internal LO backup system.

Good argument but does it outweigh the safety benefit? Don't think so. We could show an infobar asking whether this option is wanted. But this would open Pandora's door.

(In reply to Heiko Tietze from comment #16)
> Good argument but does it outweigh the safety benefit? Don't think so.

OK - I should have tested before I complained. My complaint only applies if the .bak file is stored in the same folder as the working document. However I see that the default backup location for Linux is .config/libreoffice/4/user/backup and I assume something similar will be true for Windows. In that case my specific complaint is null and void.

That does raise a different potential concern though. Hardly ANYONE will ever discover that a copy of all their documents now exists in some hidden spot. That could be a rather sensitive privacy concern, as well as a lost-disk-space concern (although that is pretty much irrelevant with today's minimum of 500 GB drives.)

Pointing this out is probably worth a prominent place in cui/inc/tipoftheday.hrc.

I care about my backups, so I change the default backup location each time I install a new LibreOffice version. Of course, 99,99% of people don't know and don't do that.

(In reply to Justin L from comment #17)
> 
> Pointing this out is probably worth a prominent place in
> cui/inc/tipoftheday.hrc.

I can add something about that in the Tips of the day, somewhere between first one. If you have an ideea and I will work on it to be ready for Tips. Just some thoughs about how this can sound.

A couple of bugs, I had in mind: bug 106208 bug 144512 bug 144512 (all by the same reporter; not me). Something else to look out for: bug 59365 

A more hypothetical: it might be that auto-save will cause more, odd cases, where the save will make LibreOffice crash because of some temporal layout state at point of save. (For native format or something like DOCX) Obviously a crash on save shouldn't happen (a bug by it's own), but well creating repeatable steps in those case will be hard to come by.

-------------
Comment 17
(although that is pretty much irrelevant with today's minimum of 500 GB drives.)

BTW, there still lots of (new) laptops sold with 256 GB SSD's (Windows or Apple), sharing OS, and some applications etc.. Assumption of 500 GB drives is pretty ambitious.

---
However this only gut feeling, I'm lacking hard data. Time will tell if there any complains and what the entail.

(In reply to BogdanB from comment #19)
> If you have an idea and I will work on it to be ready for Tips.
I'm not going to suggest any wording because I still think the "backup copy" part should be reverted, and thus no need for the tip :-)

If the user manually turns "save a backup copy" on, they will figure out (without a tip) where the backup copy is stored. [I would argue that an undiscoverable, automatic safety measure won't help anyone except the desperate person who asks for help. Most people will still lose their work and have no idea that a previous version was available.]

Please note that I am in favour of "run autorecovery during user idle time every 10 minutes" (as long as it works well) because
* it is discoverable (a wizard steps you through recovery if something exists)
* it is temporary (filename.ext_0.odt stored in hidden backup folder until successful recovery or save)

(In reply to Justin L from comment #10)
> So we have enum class Job with types AutoSave, EmergencySave, UserAutoSave
> (the backup copy).

I just experienced a power failure. When I restarted Collabora Office 22.05.6.1
it prompted to restore my working documents (and this sounds very familiar to previous experiences with LibreOffice). I do not have autosave turned on.

So then either emergencySave is also a timed thing, or there is a fourth Job at work. Unfortunately the code is littered with "DOCUMENT ME" tags. So I'm really not sure what the implications are of turning on Auto(Recovery)Save and how it differs from what runs by default.

I have downloaded 6.2 .deb version:
- Save AutoRecovery is checked with 10 minutes.
- Always create backup is NOT checked.

I have downloaded 7.2 from AppImages:
- Save AutoRecovery is ckecked with 10 minutes.
- Always create backup is NOT checked.

I have downloaded 7.3 from AppImages:
- Save AutoRecovery is NOT checked.
- Always create backup is NOT checked.

Should we remove "Always create backup" as automatic ON?
I though this was always checked, but it seems "I" am always checking it after each install. But it was never a default with a new install.

In the next week I will do more tests like this:

In a big document I will make some changes so LibreOffice will be busy, and, with terminal open to see the most consuming process, I will kill the process (for example kill pid 61765) and get a recovery.

I will see which version is better to preserve my work. 

But I need a week to test.

(In reply to BogdanB from comment #23)
The change from AutoSave from on to off in 7.3 came from
commit 6f07012a344101f2afbf9c96dc7857127f39a25f
Author: Noel Grandin on Fri Jul 23 20:05:19 2021 +0200
    use officecfg to retrieve AutoSave

https://gerrit.libreoffice.org/c/core/+/119459

Created attachment 184287 [details]
demo document

I finished the experiment. Look what I did.

After/before each experiment I did this:
- Reset to Factory Settings
- Change the AutoRecovery to 1 minute (in order to be under the 2 minutes for killing the process ID)
- change the default path for backup to another folder (in order to see the results)
- remove any existing backup if there is one (anyway the documents have different name so, this was not so important)

The procedure was:
- open the document (20 pages with text)
- copy and paste all the content, without saving after that
- check in terminal with top and press "A" to see the process for LibreOffice and set in another terminal "sleep 2m && kill pid [PID of LibreOffice]"
- after LibreOffice close check the number of pages (20 pages if things are set wrong, 40 pages if I set things right)

Case 1
- No check in AutoRecovery (AutoRecovery is set to 1 minute, but uncheked)
- No check in Backup
The result: The work is lost, no backup, I have just 20 pages instead of 40

Case 2
- Check the AutoRecovery to 1 minute
- No check in Backup
The result: The work is saved, no backup, I have 40 pages. Everything is fine

Case 3
- No check in AutoRecovery
- Check the Backup
The result: No save, so no backup, the work is gone, no backup, I have 20 pages.

Case 4
- Check the AutoRecovery to 1 minute
- Check the Backup
The result: The work is saved and I also have a backup copy of 40 pages. The result is the same like in case 2, but I also have a duplicate copy in backup folder.

After all, Auto Recovery is very important to be checked (everytime when it was check it saved the unsaved work), but not necessarily the Backup (set or not, the work is saved, the disc size could increase if is set).

(In reply to Justin L from comment #25)
> (In reply to BogdanB from comment #23)
> The change from AutoSave from on to off in 7.3 came from
> commit 6f07012a344101f2afbf9c96dc7857127f39a25f
> Author: Noel Grandin on Fri Jul 23 20:05:19 2021 +0200
>     use officecfg to retrieve AutoSave


That should have been fixed as a side-effect of a follow-up commit
   commit 134f40136a9bea265d8f2fedfdb41a1e65d81b49
   Author: Noel Grandin <noel.grandin@collabora.co.uk>
   Date:   Sat Jul 24 16:56:15 2021 +0200
   use officecfg to retrieve OdfDefaultVersion

because of some left-overs from the first commit.

*** Bug 155497 has been marked as a duplicate of this bug. ***

*** Bug 155522 has been marked as a duplicate of this bug. ***

Created attachment 187765 [details]
noBackupCopy.oxt: for someone (like me) who wants to override the new default

This extension sets the default for CreateBackup to false. The user is able to opt-in if they want.

I prefere both to be off by default or at least easy way to turn it off.

Right now with LO 7.5 on Linux, even if autosave is turned off , file goes to saving mode every 10th min. I don't want that.

Autorecovery and autosave are good if they are efficient.
In case of LO both take lot of time and consume 100% of Ram and processor.
I am using complect Calc files often more than 50 mb size.
Often it happens during my ongoing work the file goes to autosave and freezes for long time.

The issue worsen if I have pressed Save button and on similar interval autosave is triggered. The file goes in save mode forever ... Needs to be killed !

So better is keep this setting at user descretion. Dumb users anyways are going to loose data

I think this change in defaults should be mentioned in the help pages, possibly at the top of:

https://help.libreoffice.org/7.6/en-US/text/shared/guide/doc_autosave.html

Bogdan, could you possibly follow up with that?

The change is already in the release notes: https://wiki.documentfoundation.org/ReleaseNotes/7.6#Core_/_General

Verified in:

Version: 7.6.0.0.beta1 (X86_64) / LibreOffice Community
Build ID: be55b15d98c5f059483845a183fcb5ea8023d27c
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

I strongly recommend that this be reverted for 7.6 (i.e. delayed until 24.2). Mike and I have started fixing a lot of autosave bugs in 24.2 (which can't be backported because of UI/translation changes).

One strong indicator is that my comment 30 extension already will no longer work in 24.2, because of configuration fixes.

AutoSave is not in very good condition in 7.6, so it shouldn't be turned on by default at this point in time. https://gerrit.libreoffice.org/c/core/+/154578

Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/24bf5a2bfaae62e6e0218a4f2521f54e816cd459

Revert "tdf#152463 Turn on AutoSave and Backup by default"

It will be available in 7.6.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0e17d8ddccdee7d4f46b256153853e1cab87c99e

partial Revert "tdf#152463 Turn on AutoSave by default"

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Comment 36 did NOT turn off AutoSave for 24.2.

AutoSave was enabled in 7.2 by default, broken in 7.3, and fixed in 24.2 thanks to bug 156308. So the default of AutoSave (Enabled) from 7.2 now applies to 24.2.

Comment 36 just reverted the change to a now-deprecated setting, since historically this particular setting has always defaulted to false. Hopefully a false setting will clue people in that this is not the right setting to use for enabling/disabling AutoSave.

(In reply to Justin L from comment #34)
> One strong indicator is that my comment 30 extension already will no longer
> work in 24.2, because of configuration fixes.
This statement is incorrect. CreateBackup was not affected by officecfg changes (and I didn't include AutoSave in the extension), so the extension is still fine.

Created attachment 188884 [details]
1 before save

Created attachment 188885 [details]
2 while save

Created attachment 188886 [details]
3 after save

(In reply to Telesto from comment #6)
> but autosave sadly isn't something done silently in the background

What about implementing some kind of announcement e.g. in the status bar informing that the saving is running now?

E.g.
1) Progress bar -> display text for 5 second after finishing: "Done".
2) Display text: "Saving runs" -> display text for 5 second after finishing: "Done".


And when the saving process has been triggered automatically, with additional reference to options that we could turn off backup or autorecovery, or change delay between.

(In reply to Piotr Osada from comment #40)
> Created attachment 188885 [details]
> 2 while save

I just lost some work to this issue in a system hang, was very surprised to see that autosave wasn't enabled by default.

Version: 7.6.0.3 (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 6; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: en-CA (en_CA.UTF-8); UI: en-US
Flatpak
Calc: threaded

The install of LibreOffice has been updated over time on this system, and the version at install was probably affected by the old default.

For my curiosity: was the patch intended to change the autosave setting for existing installs after updating? Or will only new installs have autosave enabled by default?

Thanks

(In reply to Patrick from comment #43)
> I just lost some work to this issue in a system hang, was very surprised to
> see that autosave wasn't enabled by default.
> 
> Version: 7.6.0.3 (X86_64) / LibreOffice Community
> Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
> CPU threads: 6; OS: Linux 6.2; UI render: default; VCL: gtk3
> Locale: en-CA (en_CA.UTF-8); UI: en-US
> Flatpak
> Calc: threaded
> 
> The install of LibreOffice has been updated over time on this system, and
> the version at install was probably affected by the old default.
> 
> For my curiosity: was the patch intended to change the autosave setting for
> existing installs after updating? Or will only new installs have autosave
> enabled by default?

New installs should not mess with old settings in the user profile.

(In reply to Buovjaga from comment #44)
> (In reply to Patrick from comment #43)
> > For my curiosity: was the patch intended to change the autosave setting for
> > existing installs after updating? Or will only new installs have autosave
> > enabled by default?
> 
> New installs should not mess with old settings in the user profile.
Buovjaga is correct, but the answer is a bit more subtle than that for autosave.

Short/simple answer: autosave every 10 minutes will be enabled in 24.2 for both old and new profiles. However, the backup copy will only be enabled for new profiles.

Longer answer: autosave every 10 minutes was default for a long time, up until 7.3 mistakenly started using a different autosave config that defaulted to off. LO 24.2 fixes that 7.3 mistake, so if your profile originated from BEFORE 7.3 and you had turned autosave OFF, then it will still be off in 24.2. You will also retain your old time interval if you changed it before 7.3.

If your profile originated in 7.3 - 7.6, then 24.2's autosave will be enabled every 10 minutes, regardless of the time interval set in 7.6.

See comment 37 if you want to try to understand the distinction.

(In reply to Justin L from comment #45)
> However, the backup copy will only be enabled for
> new profiles.
There is a bit of ambiguity here too. If you made NO customizations to the Load/Save area, then the 7.6 defaults are not necessarily written into your config file, and thus you may still get backups enabled automatically.

Pierre F committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/f9c2c4f00d219221d8e06a0961b0594835d94958

tdf#152463 tdf#144511 AutoRecovery and backup on by default

> good grasp of file management or version control. If there are multiple
> copies of the same file in the same folder they will easily get confused.


In 2024 I don't see extra copies. Just a .~lock. while editing but nothing in there. The autosave is hidden from user.

(In reply to Tom Atkinson from comment #48)
> > good grasp of file management or version control... (from comment 15)
> 
> In 2024 I don't see extra copies. 
Yes. Comment 15 was qualified/nullified by comment 17. There IS an option to save the backups into the same folder as the document itself instead of in the hidden user profile - but it is not turned on by default.