Revert Changes - changes file date/time to time at close

  1. Open older file
  2. Make changes
  3. Close file and choose “Revert Changes”
  4. The file date modified in Finder will be changed to the present date/time.

I don’t believe Rhino Mac used to do this? File date used to be preserved on close/revert if my memory is correct. Has done this for past several builds I think.

When one has lots of files one (me, and I assume others) likes to know which is newer and which is older by date modified. If I open a older file just to have a look, copy elements, etc, and turn on/off some layers, close/revert…I get a fresh file date.

This is not helpful for organization, etc.

wouldn’t be good for el Capitan’s natural language queries thing either :wink:

(not my screenshot-- i haven’t tried it yet… i thought it was neat when i saw the demo but not sure if it will be something that i eventually use or depend on)

Bump…no response from HQ?

Is there a way to retain the previous file date when choosing “Revert Changes” on close?

On my systems, if I open an older file, poke around, and then choose “Revert Changes”, my file reverts, but the files date is updated in Finder to the present.

This can be inconvenient when reviewing file changes by date, which is very handy when one has lots of files/revisions, etc.

Is a fix for this possible? Is the issue Rhino or Versions? I may be wrong, but I seem to recall that older builds retained the previous time/date after a “Revert Changes”.


I can’t reproduce this behavior on my machine. Here is what I do:

  1. Open RhinoWIP (5B148w).
  2. Draw a box centered at the origin.
  3. Save the file as “RevertTest.3dm.”
  4. Close the file.
  5. Select the file in Finder, Get Info. Write down “Modified:” time (say 11:53 am).
  6. Run and grab coffee…come back in 5 minutes.
  7. Open “RevertTest.3dm” in RhinoWIP (5B148w).
  8. Move the Box.
  9. Close the modeling windows. Revert Changes.
  10. Check Finder’s Get Info on “RevertTest.3dm.”

Expected Behavior: The Modified time says 11:53 am.
Actual Behavior: The Modified time says 11:53 am.

What could I do differently to reproduce the behavior you describe?

Are you seeing this behavior on your machine in the latest RhinoWIP?

Thanks for investigating. Yes, 5B148w and going back a while…

When I follow your steps, I can’t reproduce either, which confused me big time, because I see this all the time. First I thought perhaps such is related to a movement between volumes issue…but no, I follow your “RevertTest.3dm” method, change volumes and machines, all good!

Could it be a cross platform issue? I think I’ve reproduced in a new test file this by doing the following:

  1. Create “RevertTest.3dm.” file (note modify date)
  2. Open in Rhino for Windows, make change, and save. (note modify date)
  3. Open in Rhino for Mac, make changes, wait for versions autosave to occur
  4. Close the modeling windows. Revert Changes.
  5. Check Finder’s Get Info on “RevertTest.3dm.”

Do you see a fresh modify date? (fresher than the Windows save date)

Also. perhaps the file is permanently FUBARed thereafter, in terms of the modify date / Versions that is.

  1. Make changes in Rhino Mac, save
  2. Repeat test steps and you may see a fresh modify date after each successive Revert Changes.

Are you able to reproduce? If so, is this cross platform issue surmountable?

Thank you

any file you bring into your mac will have it’s created/modified date set at that time…

for example… here’s a .3dm from a few years back…

up_cee.3dm (195 KB)

…download that then do a Get Info on it… the dates will be different on your system. (right?)

Yes, and that makes total sence. (Normal)

The subtle difference that may be happening, which I did not realize until I dug deeper, is that the revert/date mechanism seems to break permanently into future saves after the platform move.

In my test case, the file was on the same volume and touched first by Rhino Mac, then Rhino Windows via boot camp. After being touched (saved) by Rhino Windows, and receiving a fresh modify date (expected behavior), subsequent revert activity on Rhino Mac received a fresh modify date each time. Even if altered and saved on the Mac (expected behavor) future revert attempts get a newer fresh date, seemingly into perpetuity.

In other words, the date mechanism seems broken thereafter. Perhaps this is just the nature of a platform hop? Dunno.


Save file Mac Jan 1
Save file Win Jan 2
Save file Mac Jan 3
Revert file Mac Feb 1 - modify date changes to Feb 1
Revert file Mar 1 - modify date changes to Mar 1

Sorry for the late reply. I tested this between VMWare Windows 10 with Rhino 5 for Windows and Rhino 5 for Mac (5B161). Just to add a wrinkle to what has already been tested: going between these two systems (one native, one virtual), it’s as if Windows (virtual) created the file after step 2’s save in Windows. So, when I get to your Step 3, the date system is already broken.

I really doubt it. This is going to be interesting when implementing cross-platform file locking for Worksessions.

Thank you for clearing this up Dan, and I apologize that I had not originally connected this to files coming over from Windows.

For users migrating to the Mac version from Windows, with legacy Windows files, those wanting to be able to “poke around” (examine, change layer states, but commit no file change) who also want to retain the original last modify date (for “bookkeeping”, etc) need to know to poke round with a duplicate file, hence loose Finder date filtering as soon as Versions kicks in.

On my end, Versions is not changing the reported Revision History shown in the Audit3dmFile command, e.g.:

Revision History:
  Create Time: Tuesday August 16 17:54:49 2005 UCT
  Last Edit Time: Thursday October 15 19:50:41 2015 UCT 

Not terribly useful for checking this in Finder, I realize…but…might be a good backup in a pinch.

As far as I’m concerned, this can of worms is still open.

Good to hear, thanks.

For many years my cross platform workflow has centered on HFS+ volumes, with software on the Windows side to read/write to HFS.

Therefore, if I want to retain OS date filtering of my archive of Rhino files, whenever examining or copying elements out of an archived file on Mac OS, I must remember to duplicate that file (and trash the duplicate when done) hence loose Finder and Windows Explorer “by date” filtering after the Rhino for Mac revert feature fails (updates) to retain the modified date of a file the was ever “touched” by Rhino Windows.

Is this a “feature” of Versions or a condition of present Rhino Mac/Windows? If the former…bad Apple!

I do not know the definitive answer to this …yet. Given that the cross-platform workflows can be quite diverse, I think we might be asking quite a bit of the Versions feature and it may be acting as expected (my test going between Rhino 5 for Windows and Rhino 5 for Mac through a shared folder using VMWare is only one possible workflow). There are many. I don’t have enough information to disentangle this issue yet.