How to save a duplicate copy of a session?

Hi everyone, got a (probably) simple question here, however a little tricky: I need to save a exact copy of a session I’m working on, what should I do? I know most programs you’d use Save As to make a duplicate file. Ya know, it makes a new file name with same data, and keeps the original file as well (with same name). Makes two files>>that’s what I want. However Rhino doesnt appear to do this, it just changes the file name. So what options should I use? Any info appreciated, thx

Rhino does exactly what you say the other software do.

Use SaveAs or Incremental Save

Hi All
I think that what @jch51502 means is that when you use “save as”, the active file is now the “new file name”. If you are working on file A.3dm and saveas B.3dm, the active document is now B.3dm - and he/she would like to keep it as A.3dm.
@jch51502 take a look at this thread - Pascal’s made a script that does just that :slight_smile:

HTH, Jakob

Hi All - Here is a little cleaner version in case it helps.

SaveACopy.py (666 Bytes)

To use the Python script use RunPythonScript, or a macro:

_-RunPythonScript "Full path to py file inside double-quotes"

“Guaranteed somewhat tested”

-Pascal

2 Likes

If I remember correctly, that’s the main difference with Incremental Save and SaveAs.
SaveAs makes the new file current and Incremental Save does not.

Hi JB- IncrementalSave makes the new file name current. Thus, if you make a change after an I.S., and than Save, the state that existed at the time of the incremental save is lost forever. That was my gripe about this command - we changed it briefly to make a snapshot on disk and not change the current file, but that messed up peoples existing workflows. My script above, assuming I did it right, writes a copy where ever and to whatever name you want but keeps the current file current.

-Pascal

That’s messed up.
Then what good is IncrementalSave?

Thanks for your work-around script.

It’s even more confusing.

SaveAs using a file format other than the current Rhino version, for instance SaveAs a Rhino 5 file when using Rhino 6, and the current file name remains. Then if Save is used the results are a Rhino 6 file with the earlier file name, not the name of the Rhino 5 file.

On the other hand open a Rhino 5 file in Rhino 6 and then Save and the same dialog box opens as SaveAs.

Confusing with the very real possibility of losing data.

Hi David - Yes, this should save a separate file to disk and not change the current file. As far as I know that is the expected behavior. Your currently open file is in the current version, the saved one in the say, V5 version - you can’t have a file open in v6 and be in v5 format.

If you open a V5 file, and Save you get the save dialog because it is a different file - if it just saved with no questions asked, the file on disk that was V5 would become V6 and users would, understandably, be cross about that.

I don’t think there is anything amiss in what you describe.

-Pascal

@pascal What is amiss is the different behavior after SaveAs between when the file is saved in the file format of the current Rhino version versus when the file is saved in a different file format. To be consistent Rhino should either behave after SaveAs is executed in one of two ways:

Alternative A: Rhino behaves as if the result of SaveAs was opened. This is what currently happens if the SaveAs is in the current file format.

Alternative B: Rhino continues as if SaveAs was not executed (other than the new file exists on disk) and subsequent Save uses the file name from before SaveAs was executed. This is what currently happens if the SaveAs is not in the current file format.

The current inconsistency is confusing and can lead to the loss or unintended changes of data, etc It has happened to me when I’ve needed to create an edited Rhino 5 version of a file I have open.

No disagreement about that behavior. That is what I believe should happen.

Hi David - your Alternative A, if the file was allowed to be saved as other than the current version, and Rhino did behave as you suggest, would leave you in essentially the same situation as in my comment that you quote lower down - a previous version file saved to disk and a current version file open, and a subsequent Save, if allowed to proceed, would turn the V5 file on disk into a V6 one.

-Pascal

@pascal The subsequent Save would turn the file into a V6 format file only if the user did not decide to save as V5 instead. Perhaps when using Save after opening a file in previous version format a message should appear saying the last file was in a different file format than V6.

The current situation is inconsistent behavior. I understand choices were made to prevent undesirable outcomes in the two situations with SaveAs but the result of those choices is other undesirable behavior.

I guess that’s why I have never used it :smiley:
I only checked that it creates some sort of versioning.

It used to work the way I described, back when I was teaching Rhino.
That has been quite some time now.
Maybe V4.
It was handy for those, “I might need to get back here after I go try this idea” moments.

I think it has always had this weakness - when we tried to change it to be more ‘sensible’, several users howled that it broke their long-established workflows or scrips or macros etc. We had to put it back to how it is now…

-Pascal

Hi everyone, so sorry for late reply, been abit under the weather. I’m glad y’all chimed in on the SaveAs option b/c I never thought it performed as I assumed it should. I’ll probly try Pascal’s script. I’ll also test out the IncrementalSave, might work fine, just have to keep track of which version is which, as it saves via sequential numbering, rite? 005, 006, etc. Regardless, I appreciate the input from everyone. Maybe a new option should be introduced, for folks that are used the typical SaveAs behavior of most programs/apps. Ha, could call it SaveAsMirror or SaveAs Doppelgänger. Thx

1 Like