Bug 7067 - EditorSupport should create autosave files - plugin available
EditorSupport should create autosave files - plugin available
Status: NEW
Product: platform
Classification: Unclassified
Component: Text
All All
: P1 with 5 votes (vote)
Assigned To: issues@editor
: 26476 60832 201650 202284 (view as bug list)
Depends on:
Blocks: 21748
  Show dependency treegraph
Reported: 2000-07-14 19:31 UTC by Jesse Glick
Modified: 2016-07-01 18:12 UTC (History)
9 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2000-07-14 19:31:26 UTC
When a text file is open and modified in the Editor, the system (via
EditorSupport?) should (at least as an option) periodically create autosave
files, a la Emacs. It is very frustrating to lose edits to a file simply because
a beta VM crashed (e.g.).
Comment 1 Jaroslav Tulach 2000-08-22 14:30:59 UTC
Where the files should be stored?
Comment 2 Jesse Glick 2000-08-22 16:08:59 UTC
Should be in the same directory as the main file. E.g. Emacs uses .#Foo.java for
Foo.java. When the file is saved, the autosave file is deleted. If the file is
opened and an autosave file exists, you are prompted whether you want to restore
from the autosave; if you say yes, the buffer is loaded from the autosave file,
and is left modified.
Comment 3 Jesse Glick 2002-02-14 19:50:40 UTC
Still possible I guess, close as WONTFIX if desired.
Comment 4 Peter Zavadsky 2002-07-25 14:32:14 UTC
Not closing, it's a good idea.
Comment 5 Marian Mirilovic 2002-12-06 17:17:48 UTC
reassigne to David K., new owner of editor
Comment 6 Jesse Glick 2002-12-10 17:58:41 UTC
Don't forget about Runtime.addShutdownHook, which would permit NB to
create autosaves of files if the VM is shut down impolitely - e.g.
Ctrl-C on console, log out of X session, shutdown on low battery
power, etc. This could avoid a lot of situations that would currently
lead to data loss.
Comment 7 David Konecny 2003-02-27 16:40:42 UTC
*** Issue 26476 has been marked as a duplicate of this issue. ***
Comment 8 peathal 2003-07-03 16:27:14 UTC
Auto save will be fine. 
But it will be also nice to keep the files in memory. 
If you delete opened files, while working (i tried this ;-( ), from 
konsole (etc.) then normally editors keep them in memory and you 
only have to save them on disc again. 
Comment 9 Jesse Glick 2005-03-14 15:59:52 UTC
To summarize desired features:

1. While editor is open and modifications are made, should try to create
autosave files at regular intervals.

1a. In same dir as real file if that is possible, else in /tmp or something if
that dir is not writable.

1b. File naming convention a la Emacs; most software (e.g. Ant) automatically
knows to exclude such filenames.

1c. Ideally, temporarily disable autosave when buffer shrinks dramatically, to
prevent loss of much text at once, again a la Emacs.

2. Regular IDE shutdown already prompts to save open files. There should also be
a VM exit hook to write out any still-modified buffers to autosave files, in
case there is a normal (non-fatal) VM exit but that save dialog fails somehow.
E.g. in case an OOME is caught and the IDE has to be shut down with little extra
memory available.

3. Upon opening a file with an extant autosave, should prompt to load the
autosave (leaving buffer modified), or open unmodified file (deleting old
autosave file in either case).

4. If a file is modified in the editor and it is deleted on disk, should make an
autosave before closing the editor window so changes are not lost for good.
Comment 10 _ ttran 2005-03-26 22:12:15 UTC
increased priority to P2
Comment 11 melhe 2007-02-21 15:03:38 UTC
A nice, additional feature would be to extend the auto saving by doing like
Intellij; when the IDE window loses focus (developer has switched to another
window) all files are saved.
Comment 12 Jesse Glick 2007-02-21 20:07:35 UTC
I think this is pretty important. Data loss due to the lack of this feature is
not really acceptable.

See Michel's new module.
Comment 13 Antonin Nebuzelsky 2008-04-17 15:14:14 UTC
Reassigning to new module owner mslama.
Comment 14 Jesse Glick 2008-05-22 18:30:20 UTC
*** Issue 60832 has been marked as a duplicate of this issue. ***
Comment 15 Jesse Glick 2008-09-30 18:18:06 UTC
*** Issue 145741 has been marked as a duplicate of this issue. ***
Comment 16 Michel Graciano 2009-02-18 13:44:46 UTC
Hi guys,
I will implement issue #145741 for plugin http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=2404
So, will be possible save file time after time or every time user get out focus from unsaved file.
I am thinking to publish it at contrib repository, do you see any problem about it? I hope to be possible to rewrite the
tor module and create property to user define if want or not use these features, since it can be painful for people who
use CoS feature.
To keep this at nb repository I need to change license to CDDL or GPL, pr LGPL is fine for this?

Comment 17 Jesse Glick 2009-02-18 15:17:43 UTC
To be in the NB source repo it should be CDDL+GPL and I believe you will need to have signed a Contributor Agreement:

Comment 18 Michel Graciano 2009-03-11 03:47:03 UTC
I pushed my module to main/contrib. I am working at a refactoring, so the module is still buggy. The changeset is
Comments are welcome.

Comment 19 Milutin Kristofic 2011-09-07 13:31:50 UTC
*** Bug 201650 has been marked as a duplicate of this bug. ***
Comment 20 Marian Mirilovic 2011-09-20 08:57:00 UTC
*** Bug 202284 has been marked as a duplicate of this bug. ***
Comment 21 Jesse Glick 2011-10-18 18:05:31 UTC
An alternative would be for localhistory to track unsaved changes until the file is saved.
Comment 22 Tomas Stupka 2011-10-18 18:54:21 UTC
(In reply to comment #21)
> An alternative would be for localhistory to track unsaved changes until the
> file is saved.
we could do that
Comment 23 theosib 2011-10-19 02:19:37 UTC
That's an excellent idea.  It's kinda like writing a filesystem journal for uncommitted data.  When the user restarts the IDE, it just loads the saved file and then rolls forward from the journal.  As long as the journal is date-stamped properly, you'll avoid the race condition where the file got saved and then the IDE crashed before the journal could be purged.  Then there's the really bad situation where the IDE crashes in the middle of the save and trashes the file, which may be an argument for writing snapshots instead of or in addition to a journal.  Something to think about.
Comment 24 jrojcek 2011-11-11 08:07:51 UTC
Just a comment regarding the user experience when a crash happens. In ideal case, if a user restarts the IDE after the crash, it reopens all files and restores them into "unsaved" state containing all edits done before the crash.

How close to that we can get with the local history solution?
Comment 25 Tomas Stupka 2011-11-11 09:26:38 UTC
(In reply to comment #24)
> Just a comment regarding the user experience when a crash happens. In ideal
> case, if a user restarts the IDE after the crash, it reopens all files and
> restores them into "unsaved" state containing all edits done before the crash.
> How close to that we can get with the local history solution?
hm, had to figure out how to distinguish if a file wasn't saved because of a malfunction or because the user deliberately discarded the changes ... 

the question is if the LH should be:
1.) a kind of a workaround and we implement it as a separate enhancement of local history which would make sense by itself - the history of a file will also contain periodically stored unsaved state(s) and the user would be eventually able to pick/recover from them in the history view.

2.) the module completely taking over the responsibility for this feature (see comment #9) including also the smooth user friendly recovery etc.

speaking for LH i would say its 1.)

this is a useful feature, filled a long time ago. is there any technical reason this haven't been done yet by the owning team anyway?
Comment 26 phansson 2014-06-01 15:02:22 UTC
Contrary to some of the other comments on this report I believe we should take a different route when implementing an auto-save feature in NB.

My proposal is more akin to what e.g. MS Office does, i.e. periodically saving a copy of the file in *another location*. Unlike MS Office I believe that 'other location' should be the user dir, not the file's own location. This will keep the auto-save file out of any VCS.

The existing Plugin by Michel Graciano (it in HG in main/contrib/autosave) does its job by executing the save-all action at regular intervals, i.e. it is similar to manually pressing the Save-All icon from the IDE, pressing Ctrl-Shift-S, etc.

While this approach certainly gets the job done it cannot distinguish between the cases where the user actively decides to save a file or when the auto-save feature has done it for him. In contrast the 'MS Office' style auto-save does just that.  I often open a file in a IDE, change something, but do not necessarily want that change saved .. at least I wouldn't like it happening behind my back. 

What I propose here is more complex to implement in the sense I doubt it can be done by 'an outsider' in a plugin. The benefits are huge though: (1) It will be easy to implement crash recovery similar to what MS Office does on startup and people will be familiar with it. (2) We will not pollute the source tree with auto-save files. (3) Auto-save files will be local to the user and local to the workstation (which is the way it SHOULD be).

Apart from the fact that I'm not sure my proposal can be done in a plugin I believe it is a lot cleaner, easier to understand, stays out of the source tree and generally avoids some of the issues discussed above.
Comment 27 lucrus 2016-01-13 08:05:24 UTC
I agree with phansson (comment #26) and I've just lost part of my work because of a crash and the missing autosave feature in Netbeans.
Comment 28 markiewb 2016-07-01 18:12:02 UTC
A plugin is available for that


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo