Multiple autosave files

Hello all.

As far as I understand, Audacity currently creates single autosave file (under linux in ~/.audacity-data) if there is open, modified project. Frequency for autosaves is set by user. This file is deleted after closing the project.

Wouldn’t it be a useful feature if user could set “maximum number of autosave files” so that some number of older autosaves would be kept? This way, for example is set to six files with 10 minutes interval, always there would be possibility to step back up to on hour. Audacity project files are small and most user could actually keep a lot of older autosave files, just in case.

Also - I think that deleting autosave file after closing/saving project is not a good behaviour and further reduces possibilities of recovering from bad accidents.

Regards,
Adam

One shouldn’t depend on Auto Save to do anything useful. It doesn’t do what most people think it does and it was never a good, stable, desirable product.

The real request is to add the auto-save to Audacity that everybody wants. Your computer goes up in a ball of digital flames and after you mop up the mess, you can simply launch Audacity and open up the last known good auto-saved show. I believe that’s only available as a product request right now.

Koz

Frequency for autosaves is set by user.

You must be using an older version of Audacity. The autosave interval has been gone for several versions. Autosave is now done whenever an Undo state is added.

This file is deleted after closing the project.

Yes, because the purpose of the autosave is to be able to recover the project in case of a crash.

Wouldn’t it be a useful feature if user could set “maximum number of autosave files” so that some number of older autosaves would be kept? This way, for example is set to six files with 10 minutes interval, always there would be possibility to step back up to on hour. Audacity project files are small and most user could actually keep a lot of older autosave files, just in case.

As long as the project is open you can back up as far as you want. Saving does not clear the Undo history. It sounds like you’re asking Audacity to keep a kind of “Time Machine” history of an arbitrary number of projects.

One shouldn’t depend on Auto Save to do anything useful. It doesn’t do what most people think it does and it was never a good, stable, desirable product.
The real request is to add the auto-save to Audacity that everybody wants. Your computer goes up in a ball of digital flames and after you mop up the mess, you can simply launch Audacity and open up the last known good auto-saved show. I believe that’s only available as a product request right now.

Wrong on many counts. The improved autosave is very robust an does exactly what you say you want it to do.

– Bill

Audacity 2.0 (and the last few 1.3.x beta releases) accomplish that pretty well.

What the auto save does not protect against is if the user messes up the project and then the computer goes up n a ball of flames. In this case the recovered project would have the user’s messed up project and no Undo history. The only way to come back from that is to keep regular manual “full project” back-ups. Perhaps it would be a reasonable feature request to have a feature for: “Make full project backup copy when idle: Minimum backup interval [ 20 ] minutes.

Bill:

You must be using an older version of Audacity. The autosave interval has been gone for several versions. Autosave is now done whenever an Undo state is added.

Sorry, didn’t take this into account (I only checked 2.0 release notes for updates into autosave). I’m using 1.3.12 (on Ubuntu 10.04).

As long as the project is open you can back up as far as you want. Saving does not clear the Undo history. It sounds like you’re asking Audacity to keep a kind of “Time Machine” history of an arbitrary number of projects.

But after you close the project, there is no going back. I think most users would be perfectly OK with giving few Megs of hdd space for Audacity to keep “Time Machine” for their projects. If you do editing, not recording, keeping older project file gives the possibility to revert some wrong changes and this can simply save hours of work.


Yes, because the purpose of the autosave is to be able to recover the project in case of a crash.

I started to think about autosave in audacity this Tuesday after I experienced a crash. Let me tell you the sad story. We’ve been recording a song with friend. We used Boss gt-10 as a sound card input (usb connection). After session we had about 800 Megabytes of audio recorded, about 10 tracks. Unfortunately, when I was doing final edits my friend unconnected guitar processor. This caused whole system to hang (not sure why, I did it many times and allways worked OK). After restart, both audacity project and autosave file were zero bytes size. Obviously recover functionality didn’t work. I was stuck with 800 megs of audio in audacity part files, with no way to bring it back together as I didn’t have any valid audacity project file for it. Also scanning drive for recovered files (using very good Photorec) didn’t help - it only found parts of the project file. We had to repeat the session.

I’m not a filesystem expert but I think that files that were open by audacity got corrupted because of system crash. I’m pretty sure, however that having older backups that are not deleted after closing audacity would have saved me in this situation.

Of course I understand that this was quite rare accident. I would be glad to know your thoughts on this.

A

Then you need a system to choose the particular backup aup or autosave to use, with all the complications that has of inexpert users choosing the wrong backup, and then the backup relating to a project state in the temp or _data folder that no longer exists. We stopped having backups of older projects for that reason several Beta versions ago.

Maybe but that needs a lot of disk space as (I think) you mean saving a complete new _data folder. You can do this manually now with File > Save Project As.

An alternative way is to store the Undo History in the project. It makes for larger _data folders, but not as large as a separate copy of the project. I think this is possibly the better feature to vote for.

There is a case to make a backup of the current aup or autosave file to cover the case where these are not saved or updated correctly. The aup/autosave is saved last so is vulnerable. Incorrect saving does happen occasionally on Windows. If it happens, there is no easy way to open the audio data in the absence of a backup.

Audacity recovery is much more reliable from 1.3.13 onwards because every action regarded as changing the project state is saved, rather than using a time interval system. This does (as currently implemented) make editing and moving around the project slower, something we still have to address.

However this case you raise where the aup or autosave are missing or null would obviously benefit from having a backup made of the current aup or autosave every time it is written (with deletion of the previous backup). I’ve already raised this recently with a developer who thought it well worth considering.

I won’t add your vote yet for periodic full backups, saving undo history in the project, timed multiple aup/autosave files or keeping a backup of only the aup or autosave file just saved. Feel free to say which you prefer.




Gale

Yes it does, yes I do, yes I do.
When I’m working on an important project I save the project at roughly 30 minute intervals, naming the projects “project-name001”, “project-name002”, “project-name003”…
It does take up a huge amount of room and it requires the user to remember to make the back-ups. Such a process could be easily automated, but there is probably a much smarter and more efficient way to achieve the same level of security, such as …

and to make periodic back-ups of the .AUP.

Currently backing up the .AUP file would be of limited usefulness because after saving the project there could be data required by the back-up that no longer exists. An option to include the History would make .AUP backups useful (especially against a corrupted .AUP file).

Assuming the project saved correctly on quit I would envisage then deleting the backup, even though both files could reopen the project. If the aup and backup .aup did not match, Audacity would keep both files and warn on re-opening.

I would hope saving history in the project could obviate the need for “previous state” .aup’s without a separate _data folder. I think the risk of abuse and confusion is probably not worth the benefit.


Gale

Apart from using up potentially lot of disk space this would cause audacity to start transferring a lot of data in unexpected moment, this could seriously disturb the work. Detecting idle state is not not a perfect solution, you can never be sure that you won’t start backup in the same moment that user was to hit the ‘record’ button.

I think that it is perfectly OK to leave making full backups of the project to user. Actually the simples solution seems the best one to me - just use alarm clock application to remind you to do full backup no later than the time you choose. This way you have full control over disk usage and selecting moment of backup.


This seems very good idea to me. It would probably require adding something like “purge” option to let user wipe backup history data in order to save space when he or she is sure that there will be no need to go back. I think this is the solution that many programs use. As Steve mentioned this would work perfectly together with creating timed backups of AUP file.

Man, it would be so cool if I could open my audacity project in the morning and just CTRL+Z the silly change I have made the day before - don’t you think?


However this case you raise where the aup or autosave are missing or null would obviously benefit from having a backup made of the current aup or autosave every time it is written (with deletion of the previous backup). I’ve already raised this recently with a developer who thought it well worth considering.

Agree. Having multiple backups (deleting the oldest one) further increases the chance of recovery (for example when scanning the hard drive for lost files).

I won’t add your vote yet for periodic full backups, saving undo history in the project, timed multiple aup/autosave files or keeping a backup of only the aup or autosave file just saved. Feel free to say which you prefer.

Gale

My votes (summing up above thoughts):

  • periodic full backups - NO
  • saving undo history in the project - definitely worth considering however it seems quite complicated feature and could require more discussion
  • timed multiple aup files backup - YES, if previous feature is implemented (I think that these should be hidden files in the project directory)
  • keeping a backup (or multiple backups) of autosave file just saved (for crash recovery) - YES

Regards,
Adam

OK I added appropriate votes directly to Feature Requests, thanks.



Gale