Autosaving in Grasshopper 2.0

Given how often AutoSave in Grasshopper 1.0 fails to actually protect from loss of data, what sort of mechanisms would you like to see? Should autosave files always be next to the original? Or would you rather have them all in a special folder? When is it okay to delete autosave files? Should they be time-stamped? What sort of control do you want over when an autosave happens? Etc. etc.

2 Likes

David, thank you for opening up this discussion. My ideal Autosave improvement in Grasshopper 2.0 is as follows:

Mechanism 1 - Autosave files are always saved in the same folder where the original file is saved. The number of autosave files can be customized, and the oldest autosave file is deleted whenever the newer file is saved.
Mechanism 2 - Autosave files are stored in a separate folder like the current Grasshopper version, but users can customize the duration of those files are saved in the folder like several months.

There’s redundancy in this way, which gives more chances for users to recover lost Grasshopper files.

4 Likes

Auto save in same folder; custom number of auto saves with first in first out approach.
Time should be custom too; but obviously under

Eg. autosaves set to 5 instances, at 10 Min intervals;
At the 60 Min mark the first autosave removed as the 6th is added…

1 Like

My proposal is not a “proper” autosave but I think it has to do with it, and with the save state capacity of GH.

I´m working with a lot of design space exploration, several tens of variations for the same project. I would need like a kind of CVS (don´t know if it is the proper concept), and as the GH flie size is in the order of 1/1000 of the Rhino file r the same project, I supposed even if having a CVS system (with explorable backups) would mean storing 1000 copies of the same file, it would be worth it.

2 Likes

At the moment autosave files are named based on the hash of the original file. This makes it easy for GH to determine whether two files match up, but impossible for the user. If a special folder is used, what sort of naming scheme would work for you?

So you’d prefer a timed interval rather than the current approach of saving before a potentially dangerous change goes into effect?

My proposals.

  1. Add auto save to a document that has not yet been saved. I wasted a lot of time because of this, and the autosave wasn’t there to make up for my mistake. You only need to save a temporary file somewhere when a new document is created, and when the user saves it, it is destroyed.
  2. Have more than one autosaved file per document. Maybe one for each gh session. In this way, if Rhino is broken and you recover the document, since then another autosave file is created, to preserve the one that saved you, and thus avoid keeping the error above.
  3. I prefer that they are stored in a folder, like now.
  4. Never delete them, why do that? They weigh very little… Perhaps every 1000 open sessions, gh can suggest recycling these files to the user.
1 Like
  1. Create a user modifiable parameter that tells how many versions of a file to keep (default = 10).

  2. After each recompute operation, save the current version of the file in the Autosave directory. If there would be more than the number of versions specified by (1), delete the oldest version before saving the current one.

  3. Use the current file name + timestamp to name the saved file.

  4. At GH startup, check the size of the Autosave directory. If it is larger than 10% of the disk capacity put up a message on the startup screen that suggest checking the contents and deleting unnecessary files.

  5. Add a File menu option for “Empty Autosave folder.”

Embed a version control system and save to a single backup file location. We’ll need to implement this with the 3dm file too so both are saved at the same time and kept in sync.

2 Likes

Grasshopper files can be large, if they contain lots of internalised data. This also makes them save slowly, so maybe it makes sense for AutoSave to omit this data?

2 Likes

What if you have two files that have the same name but are located in different directories? How will you tell them apart when their autosaves are all in the same directory?

Is that approach compatible with schools and other orgs that have a computer lab setup? Could the central location be online?

2 Likes

Let’s consider git is the embedded version control system(since it is probably the obvious choice. There would be a folder on the user’s computer named autosave that would be a git repository (most likely in the same appdata location that we use for everything else). The folder would contain a map file which stored paths to the active files and a uniquely named file inside the folder (probably a uuid).When autosave occurs, you would save the current gh file and then copy it to a matching uuid file in the folder based on the map file + a git commit. The repository would not be super useful outside of the context of GH/Rhino because it would just be a directory of uuid named files.

This would allow for things like reviving old versions and potentially looking at what has changed.

3 Likes

GAK! Would a reasonable person actually do that? (Reasonable is the key word there.) But your point is well taken: if something can be done, someone will certainly do it.

One answer might be to put the directory name in front of the file. But this fails for those situations where someone has made same named subdirectories in different places.

So how about filename + timestamp + your current hashtag (of it’s not too long).

This was going to be my recommendation: that ignoring internalised data be an option for autosave. Also, seconding Dani in that new files have an autosave capability as well.

Ooh, good question.

Would depend on how good it is at sniffing catastrophic issues is (no slight intended)…

I like that with timed your nervous user can set 50x autosaves and 5 Min interval.

That said, I mainly use my manually archived saves/autosaves to retrieve something I destructively changed and no longer exists…
EDIT: I clearly don’t experience many catastrophic issues :slight_smile:

Yes, the current autosave files names in a special folder are not useful for users. I imagined AutoSave files following the original file names in a separate folder for my preferred improvement. Files both in the original and a separate autosave folder are essentially same, but only designated number of autosave files are exposed in the folder with the original Grasshopper files to keep the folder clean.

Hi.
Just lost a whole day’s work and was looking for a solution for automatically deleted autosave .gh file and there seems to be none.

I am really confused. Why would you want to delete autosave file? In my case, I always habitually assumed grasshopper save my work automatically so I never press Ctrl+S when working with grasshopper. But this time I was working in cluster and it crashes.

No recovery, No previous versions. Nothing.

A GH file is only 100KB. I have a 3TB harddisk. I don’t mind having 10000 of them. Please fix this. It isn’t the first time I lose my work due to autosave.

Warm thanks to Daniel and the developer team.

Sorry if im coming late to this but i also lost all be grasshopper script.
Im sure i was saving it all the time.

My Autosave folder is empty.

I did notice however .cache files in my case located at
C:\Users\Ed\AppData\Roaming\Grasshopper\ScriptBackup
eg 636893337454339077.cache with a time stamp.

I managed to open this text file with NotePad. Its scrambled but editable.

Just thought ID mention it in case its of help to anyone but also I see no reference to these .cache files in these discussions - maybe I missed it.

Not sure if there’s a better way to open these ,cache files rather than NotePad?

The cached scripts can be loaded from within the script component editors (bottom left).

How did you lose the file? Did it become unreadable? Did it disappear?