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.
(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)
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”.
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:
Create “RevertTest.3dm.” file (note modify date)
Open in Rhino for Windows, make change, and save. (note modify date)
Open in Rhino for Mac, make changes, wait for versions autosave to occur
Close the modeling windows. Revert Changes.
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.
Make changes in Rhino Mac, save
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?
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.
example:
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.
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.
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.