#44 Auto Save

Build (5)

Many programs now have autosave features, and now I and many others probably never think of doing regular saves anymore.

Possibly because computers are so reliable, but they still crash from time to time. Its brought to my attention lately since we are using laptops and are not always able to put it safely into standby/hybernation. I just lost my page that I spent much deserved creative time on.

Patrick M.


  • Nobody/Anonymous

    Logged In: NO

    Auto Save is very dangerous when you are experimenting with changes on a web document!!! Like many many developers, I frequently try out ideas and then reject them by not saving the document. With auto-save, the last or second last version of any experiment will be saved and later, when I upload new files, I'll notice the new date and risk uploading the changed and unfortunately saved experiment.

    Auto-save is an absolute no-brainer. Do NOT implement this idea.

    Anyone who doesn't think about saving a document they have been editing and depends on auto-save is also a no-brainer...

    dr john

  • Frédéric Chateaux

    • labels: --> Build
    • milestone: --> 0.8b2
    • priority: 5 --> 8
    • assigned_to: nobody --> fabiwan
  • Philip Goddard

    Philip Goddard - 2010-02-02

    I do appreciate that for some purposes autosave would be a serious problem. I myself would much prefer to have an autosave function, BUT with the ability to very easily switch it on and off.

  • Fabien Cazenave (kaze)

    If we implement this auto-save feature, it sure won't be enabled by default. I haven't heard of any development tool (text editor, IDE) that auto-saves files by default, there must be a very good reason to that.

    -- kazé, KompoZer lead dev

  • Mark Whitis

    Mark Whitis - 2010-12-10

    The comments against auto-save are based on ignorance, including, perhaps, experience with a few bogus autosave implementations.

    Only a complete idiot would implement auto-save in a way where it overwrites the original file; a few such idiots do exist. A properly implemented auto-save does not ever overwrite the original file except when given explicit permission by the user during an auto-save recovery operation. Instead, it auto-saves to a new file.

    If the program pauses while auto-saving, then it should display a message telling the user why. Auto-save should not try to save when the user is not idle as this can result in pauses at inopportune moments. If you follow this rule, user will rarely even notice that autosave is operating, let alone be inconvenienced.

    A properly implemented auto-save is enabled by default. Auto-save being enabled does not lead to loss of data; being disabled when user expects it to be enabled (such as after an upgrade, on a fresh install on a new machine, or on another machine) does result in loss of data. An example of a program which has a reasonable implementation of auto-save and which is enabled by default is emacs. There is no real down side to having it enabled and there is a serious downside to having it disabled.

    A properly implemented autosave does not bother the user. No pop-ups asking for permission. If you are saving the data to the right place, you don't need permission.

    It is desirable for the program to check the timestamp on the file being opened and the autosave file and notify the user if the auto-save file is newer; it may optionally then guide the user through an automatic recovery. It may optionally check other files which were recently edited by the application. However, the auto-save function is far more important than the recovery function (which can be done manually).

    Auto-save should not try to save a file which is opened read-only.

    Consistency checks which force user intervention or prevent saving should not be enabled during autosave. Just save the data.

    I have NEVER had the need to disable by default a properly implemented auto-save function in decades of use. The only actual hazard is when you are doing recovery operations on a trashed system, in which case something else is likely to write to disk anyway if it is not mounted read-only and you won't be able to save the results of your editing safely, anyway. All you can do safely is view a file read-only, which will also disable autosave.

    Lack of auto-save can result in the loss of huge amounts of work.

    Until this program has auto-save, it is, like its predecessor, entirely unworthy of consideration. I had the sense to check for the presense of this feature before even downloading the program.

    Open office is an example of a program that originally had a completely defective auto-save which would frequently pop up a message asking the user if they wanted to save their data (overwriting the original file). It was useless and obtrusive. It now has a more or less proper autosave that saves the data somewhere else and doesn't bother the user (except at recovery time).

  • Philip Goddard

    Philip Goddard - 2010-12-11

    I support this clear and well informed case for autosave from whitis - although my own attitude is less extreme and I do use KompoZer daily, but have trained myself to press Ctl-S after each few sentences or each small step in some revision. Some time ago I did try using a couple of autosave utilities, but they were both problematical in writing to the current file and not to a specific autosave file / location.

    I have autosave in Eudora, and that is potentially troublesome because it also autosaves to the original file. However, much as I'm no great advocate of MS, the autosave function of MS Word does appear to operate in exactly the way that witis describes,autosaving to a temporary file completely transparently, and offering to recover the file in the event of a problem.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks