Watch, Follow, &
Connect with Us

The Oracle at Delphi

IDE Autosave and recovery

I mentioned it in this post, which got me thinking about a new RAD Studio IDE feature; autosave. So what do you think, is some sort of time-based autosave feature something nice to have in a development tool?

Let’s spec this thing out. I think you should be able to configure the idle delay, the "modified" state isn’t cleared, and the original file isn’t overwritten (nor are the __history backups cycled). So if you’re working on MyUnit.pas, and it autosaves to a file called MyUnit.pas.autosave. Once you explicitly save the file, the MyUnit.pas.autosave file is deleted. Of course the normal __history backups are cycled and the working file is overwritten. So if certain random sub-atomic particles crash into your memory and cause a meltdown, you at least can recover the autosaves. When the IDE opens a file, it should detect that an orphaned autosave file is out there when you open a file and will ask if you want to recover the autosave by overwriting main working file. You should even be allowed to view the differences before you make that decision. How’s that for really designing something on the fly? Anything else I missed? The compare tool should be pluggable/configurable, of course. Maybe allow you to enable this only for only certain files and file types?

Posted by Allen Bauer on September 11th, 2007 under Delphi, Work |

23 Responses to “IDE Autosave and recovery”

  1. David Clegg Says:

    I asked for an autosave feature in Delphi years ago ( Unfortunately it looks like this QC entry was closed as part of an automated RAID replication run.

    In any case, my initial request was nowhere near as feature rich as your proposal so I reckon we go with your suggestion instead. :-)

  2. Joe White Says:

    Sounds like a great feature and a good plan for implementing it.

    A few details I’d suggest to include:

    - It should probably make sure to autosave .dfm files, as well as .pas. Probably any .dpr and .dpk files, too. Actually, it’d be cool if it could autosave anything you have open, even if it’s not a source file; for example, .txt, .sql.

    - Perhaps it could also autosave the .bdsproj file, if you’ve changed Project Options but haven’t yet done a Save All.

    - Make sure it autosaves *all* modified files you have open in the editor, not just ones that are explicitly part of the project. (Particularly important if you’re editing text files and want to autosave them, or if you don’t explicitly add all your source files to the project.)

  3. Li Yang Says:

    Nice to see this feature finally added to RAD Studio.

    Is this feature added to Delphi 2007/C++Builder 2007 too through the installation of Update 3?

  4. Theodore Dennis Says:

    I think this is a great idea. Recovery of an auto-save is definitely a plus with the situation you mentioned above. This feature I know has been around in UNIX (vi) for a number of years and also in Microsoft Office applications and has proven its usefulness over the years. It looks like all the bases are covered (with configurable options, etc), but I will keep thinking on it.

  5. Dennis Landi Says:

    This is a tough call. Here is why.

    Scenario A)

    There are many times when I am typing like a fiend because I am prototyping a design that is very difficult to implement (at least mentally, at the moment, in my head) and so I am surfing various bursts of inspiration by writing code. A lot it quickly, before I test any of it (because it all hangs together after its written). In times like these auto-save would be a god-send. But frankly, I’ve developed a "Ctrl-S" twitch or tick which is now just automatic in these situations.

    Scenario B)

    However, there are other times when I have a working implementation but I’ve got in mind some non-trivial enhancement/modification of which the implementation looks more like brain surgery (on my own brain while I’m awake) at first glance. Yeah, OK, so I backed up my code before surgery begins; but, I hate to need to go back to a back-up after coding down a "what if" alley. It messes with my flow.

    So anyway, back to the brain surgery. So once again I’m coding like a fiend to flesh out the ideas as they come to me; but, this time I dare NOT hit "Ctrl-S", because I am not sure at all I want to write this code to my source file until I’ve run the code a few times. So in this case, an Auto-save would still be handy, just not to my "official" source file. It would be great if I could right-click in the code editor and toggle the "Brain-storming" menu-item. Then a "Brain-storm" sub-directory would appear under my project directory and the auto-saves would go there, while my real "Ctrl-S" saves would still write normally do my source file.


  6. Jeremy North Says:

    Hi Allen,

    You guys have access to more IDE features requests than you’ll ever have resources to do. Autosave is one of those requests.

    Report No: 40093 (RAID: 249076) Status: Open
    Add "Auto-Save" with a timer to autosave files

    Viewing changes on the fly, hmmm that sounds real familiar…


    PS: Why is an email address required? Not that I mind.

  7. Chee Wee Chua Says:

    Hi Allen,

    How about exposing this to OTA as well?

    Each stage of the decision process of the autosave should call the OTA interface, hence allowing a programmer to override the decision. ;o)

  8. Allen Bauer Says:


    That’s an interesting idea… It sounds kind of like a dynamic on-demand source code "branch." That could be something to include in a source code control interface as well.


  9. David Millington Says:

    Comparison tools, pluggable, configurable… sounds gold plated to me :) Word’s one is quite simple, if the file’s there it tells you and lets you restore from it, and that’s it. No configuration or plugins or anything. I admit diffing would be handy though.

    Have you ever used Firefox 2’s feature where it remembers the tabs you had open when it crashes, and reopens with them? It’s very useful. Something like that would be a nice addition too.

  10. John Kaster Says:

    Allen, what’s the QC # for this so I can open it? ;)

  11. Mark Brindle Says:

    I’m currently reviewing a couple of products by AJC Software. Check out AJC Active Backup & AJC Directory Synchronizer. They can give you pretty much what you want with as much (or as little) control as you need. See for more info.

  12. Dennis Landi Says:

    Allen: Yes, but a very "temporary" cache, as it were.


  13. Marco Cantù Says:

    I’m all for it! Of course, if I close and cancel changes, the autosave should go (an obvious miss in your scenario). Also, I won’t autosave until the file is first saved (don’t care having backups for quick and dirty experiments)…

  14. m. Th. Says:

    Hi Allen,

    A must have thing, of course. Beside on what the others said I’ll dare to point out some other points:

    - also implement an auto-save for the desktop layout (if isn’t in the .dsk file, dunno for D2007)

    - from our small experience with these things there are some glitches to make the user experience much more streamlined (especially if the amount of data to be saved is big):
    1.) Do the auto-save only if ‘modified’ state is true. Also perhaps you can implement an ‘auto-save modified’ flag in order to not to save the same version every time (ie. to trigger only if the file was modified from the last auto-save only). Imho, it’s obvious but sometimes one can forget it (eg. Msft Project team).
    2.) Do the auto-save engine in another thread with low priority, the auto-save thread being a consumer of a ‘files to save’ TStringList having (naturally) the IDE as a producer of this list. Imho, it’s important to have a low priority (in fact I’d rather suggest BellowNormal) because if the engine will interfere with other IDE engines which use the HDD either directly either because of swapping (for ex. CodeInsight) to not cause ‘hops’ and ’steps’ producing an annoying effect. Here you can have T1 = time between auto-save occurrences (in min) and T1 = delay between saving two files in an auto-save session (in msecs) - imho, needed to allow the HDD to ‘breathe’ a little.
    3.) If you want to be _truly_ reliable then you must save the data bypassing the OS cache (see CreateFile docs in WinSDK - FILE_FLAG_WRITE_THROUGH flag. As an aside, for these flags, imho, is quite indicated to allow the programmer to specify them if I/O classes like TFileStream etc. - imho, by using mixins (which will be implemented in Tiburon isn’t? ;-) ) (recommended, imho) or interfaces, or even having an updated class with some properties more).
    4.) Perhaps you can provide an option for specifying an (remote) ‘Autosave’ directory - because when one has to deal with a large amount of files from different directories, perhaps is better to have them gathered in one place - but then, of course, you need a map/dictionary/hash (another thing which will be implemented in Tiburon, isn’t? ;-) ) which will be persisted also in the ‘Autosave’ directory. In fact, in our case a simple THashStringList will do.
    5.) An option inspired from MSO 2003 would be the possibility to save the original or the .autosave file with another name. Especially useful for .pas files because when we’ll save a pas file with another name the save engine will change the ‘unit ;’ declaration to the correct one, isn’t? ;-)

    - +1 for a TListBox/TComboBox (or even a more advanced UI) of code branches with ‘Add / Add Temporary / Delete / Push to Main / Push & Delete’ options. "Add Temporary" it’s a temporary branch which will be auto-destroyed when we close the IDE. (I know, I know, it’s a little bit different from Dennis’s proposal). But beware here, it’s very possible to have the following directory structure:

    - Source
    - ERP
    - CRM
    - CMS
    - Shared units
    - Components

    …and hence a project to have in an IDE session modified files from more directories.

    just my 2c

  15. Cobus Kruger Says:

    I think it is a fantastic idea, as long as it is properly implemented. The IDE is already doing too many slow things on the primary VCL thread:

    At design time:
    1. Tooltip declarations
    2. Help insight
    3. Code insight members list
    4. Parameter lists
    5. Evaluation at run-time

    Every now and again, my IDE just sits there for a minute. Sometimes that’s because I accidentally left the mouse hovering over a variable, sometimes because I had the cheek to type the dot character. Adding autosave to this will make everything maddeningly slow. I think I have a better idea: first move every one of these tasks to its own thread and then implement autosave.

    I already know developers who turn Code Insight off because of the delays, and the same will happen to this if it is not done correctly.

  16. Francois GAILLARD Says:

    Well…. I already have one which saved my b… more than once, specially in D2005/2006.
    I’m using an old (1999) Delphi (5?) IDE Expert from Ray Lischner that I have tweaked a bit to work in subsequent versions of Delphi.
    The little help explaning how it works:
    "The Auto Save Wizard can save your files at regular (configurable)intervals, helping to ensure that you do not lose information if Delphi or your system were to crash.
    At regular intervals, every modified file is saved into a temporary file, whose name is formed by inserting a tilde (~) at the start of the file name
    When you open a project, if there are any auto-saved files, you are asked if you want to restore the files."
    What I would add is just another possibility of triggering an autosave: whenever I compile (if I don’t do a regular "save on compile"). So the choices would be time based, compile based or both.
    I don’t really need an autosave sub version system, as I want to master what is saved and how. I just want a crash insurance "a la Word"… Just to restart from where I was…

  17. Thomas Mueller Says:

    This has been available as a wizard for years. See here:

  18. Dennis Landi Says:

    re: The too many things done in one thread issue -

    Although you may (obviously) have reasons why some of your IDE services can’t happen in their own thread, I think this particularly piece of functionality can be shunted off to its own thread so their should not be any additional performance hit on your current architecture.

  19. Uwe Raabe Says:

    I would definitely vote for an Auto Save feature! Having this already in Castalia (and others) I actually don’t use it for the following reasons:

    1. Auto Save sometimes pops in just when I’m typing - leading to problem 2

    2. Saving files removes empty event handlers, which is somewhat unexpected with Auto Save

    So I suggest these two features for an Auto Save option:

    - only save when there is no active typing or form designing
    - don’t remove empty event handlers

  20. Jose Castillo Reyes Says:

    Very nice!! Go codegear!! Go Allen!!

  21. Yahoo Serious Says:

    It’s a great feature, which is surely missing!
    A detail: "When the IDE opens a file, it should detect that an orphaned autosave file is out there when you open a file".
    I also want this when I do not open the file, but it is being used in my project[group]. My desktop (even when autosaved) does not have contain the autosaved file. I sometimes(!) have multiple instances with the same project group. E.g. one containing the client, the other containing the server. So imagine one IDE crashes, and I close/save the second one, the next time my IDE may open without the autosaved file.
    [Mind-boggling: what if both IDE's have to autosave the same file modified differently...]

  22. Marius Says:

    Most of the people who save sources have learned this the hard way (IDE and OS stability is not 100%). An autosave would solve that (although its a more or less a dirty fix to ease the pain of unexpected crashes)

    And there’s the need to go back in versions (version+date/time), ideal would be something like the standard undo-system (unfortunately that is gone if you restart). An unlimited undo&redo system would solve it (or a more advanced version engine in the __history folder).

    Anywhay, there is a lot of room to improve in that corner and i’m sure we all need such once in a while saving us the ordinary clumbsy file-restore actions.

    Btw: i would appreciate if the contents of the __history folder would somehow be stored in a database (not sure if thats possible).

  23. Victor Says:

    I would definitely turn this feature on. With an autosave interval of 30 seconds or shorter; I don’t want to loose 10 minutes of work when the IDE starts throwing error messages and/or freezes on me again (although this does not happen so often anymore with Delphi 2007 update 3). No advanced feautures are needed; just save the files somewhere, detect them when the IDE is (re)started and autorecover. This is best done on a local drive. Autorecovery information for the IDE should include the project that was being edited when the crash occured.

Leave a Comment

Server Response from: BLOGS1