Workflow for teamwork with Dropbox? "Revert Changes" causing lost updates

I share drawings with my colleague in a different location, using DropBox. We just noticed the following behavior(s):

  • he opens a drawing (in Rhino 5 on PC), causing the creation of a .rhl file that is synched to my Mac
  • I open the same drawing (in Rhino 5 on Mac). The model is opened in a writable fashion, no warnings about being edited/locked
  • I turn a layer or something on/off, i.e. no actual change, but it still turns on the “Edited” flag
  • he makes an intended change in the drawing and saves it
  • I try to quit Rhino, and get the question “Revert Changes?”
  • If I choose “Revert Changes”, the model goes back to where it was before, overwriting my colleague’s changes… In this scenario, I am after “Close without saving”. I’m NOT after “Rollback the changes I have made”.

Am I mis-using the software? Is there a different workflow that should be used? (Yes, I can save as a new name and delete, but that seems like a terrible workaround.)

I think my Rhino install should notice that the file is being edited by my colleague (by the presence of the .rhl file) and open it in read-only mode.

Also, as reflected on in a different post here in the forum, since the “Revert Changes” changes the file timestamp, it is really wreaking havoc in my filing system, which largely relies on the age of files as an indication of their applicability.

First, “Revert Changes” is the same as Close without saving. If I am on my PC and I make changes and decide I don’t want them, it is basically reverting back to the way the file was when you opened it, “Don’t Save” or “Revert Changes”.

This is an OSX thing, not a Rhino thing.

If you both are working on an open Rhino file at the same time, my answer is yes you are misusing the software. This is not Google docs / sheets Outlook etc. where you can have 2 people editing a file at the same time.

You are also creating an rhi file on the Mac side, it is just it is invisible to you both. If you see that file on your mac, don’t open the file.

I work on a team of 2 PCs and 2 Macs and we keep a lot of template files in Dropbox. We sometimes work at home where we will be opening the same files. Usually these are template files that the PC users will use “Don’t Save” when they are done with the file and us Mac users will use “Revert Changes”. This way the file is the exact same as when any of us opened it. Rarely we will get a conflicted copy. We also use Skype to let the other people know we will be opening a certain file or maybe moving a folder etc…

A side note, we usually never work on the same file. Someone else may open a file I have worked on, but never at the same time as me.


Can’t you make these files “read-only”? On a PC you can… That way your template files never get accidentally overwritten, unless someone goes in specifically and turns off the read-only attribute.


Looking into that right now. Good point.

Yes from Finder Thanks Mitch, looks like a Friday afternoon job, that’s when we do our folder housecleaning.

It might be a good idea to move files out of the Dropbox directory while actively working on them, so they can’t be opened by the other party while being edited.

Dropbox likely isn’t as aware as it could be of files being open, since it’s not really a shared filesystem, but a sync conduit that merely looks like a shared filesystem.

Or into an unshared folder. I keep all my work in Dropbox, but mostly I am the only one to see that folder.

Thanks @rhinorudi, but on my Mac, “Revert Changes” writes a new fresh copy to disc (as far as I can tell), so I’m not sure I agree with you.

To complement the scenario, here’s what we do:

  1. I create the drawing and e-mail my colleague
  2. He makes some changes to the files and calls me on Skype or phone
  3. With him on the phone, we discuss the changes, and to understand them, I obviously have to open the file up.
  4. While on the phone, he makes some more changes in his copy of the file
  5. When we are done, I can’t close Rhino unless I save the file to either a new name or do “Revert Changes”. If I do “Revert Changes”, which has happened in the past, I overwrite his changes

It doesn’t seem like “Rhino for Mac” respects the “Rhino for PC” created .rhl file that is being synchronized by Dropbox. If my version of Rhino would realize the the model is locked by another user by the presence of an .rhl file, the problem would be solved. Other software packages work this way - for example Enterprise Architect, which I have used in my previous life. It also relies on a database file format (.eap) which is much like .3dm.

It doesn’t. I remarked about this a long time ago during the Beta process… --Mitch

In theory it is the same, I never look at the timestamp, so that is not important to me. It should still be the same file as your original one before you opened it.

I am not sure what you mean by respect, if you mean your rhino won’t open because of the hi file, you have to understand how Rhino actually works. There is another thread here somewhere explaining the process. Basically when you open Rhino, Rhino creates another file, so there are actually 2 files open of the same model on the computer that opens the file.

If only one person is making changes, then all you both do is “Save the file”.

If he makes changes on his PC, then doesn’t save all his changes are lost. If you make changes and “Revert Changes” all your changes are lost.

Make sense?

This can be done, it has no relation to the hi file though. One of you just make the model read-only, before you open it.

It seems we are discussing different scenarios and I’m not expressing myself clearly enough. Here is how the problem could be tackled:

  1. computer 1 opens the file, an .rhl file is created
  2. the .rhl file is propagated through Dropbox to all computers
  3. when user on computer 2 tries to open the model, the .rhl file is spotted and the model is opened up in read-only

Obviously, there are intricacies with how to deal with delays, asynchronous operations, and unreliable internet connections, but still - the above is what I would expect. If the model was sitting on a shared file server, one would expect this, no? If not, what is the purpose of the .rhl file?

What would also solve this issue is that I could simply quit Rhino/close the file and the original file that was opened is just left in the exact state it was when it was opened.

I’m telling you again - when I close my file and say “Revert Changes”, it does not simply close the file and leave the original there. It puts back a fresh copy of it that looks like the original.

Of course! As expected. He does save the changes.

Of course!! As expected. But with the added bonus of my colleagues changes also being overwritten by my copy (that Rhino writes back on disc) with the original version.

Sounds like something on the wishlist for V6.

Of course, because Revert means you are undoing any changes. Try save instead, I may have to do a test on this when I get together at the office tomorrow.

Of course, see above. So you both have to save the file (not revert), one at a time to keep the changes if you are both working on a the same open file.

This already works on Windows. The second “opener” of the file is given the choice to either open the file read-only or not open it at all.


So I guess we have to ask to make this cross-platform, if it is possible?

Already on the “issues” list -
Unfortunately, not slated to make it into MacRhino until V 5.4


So then it is up to the person not editing the file to make it Read-Only like stated above.

I will do a little test tomorrow, maybe today if one of my colleagues comes online.

As A test here, I created a file, closed it and made it read-only to me.

I then open the file and tried to make a change. This is what I got …

So I guess for now that would be a work-around.

At this point it is getting to be my 5¢, not 2¢. FWIW

Thank for the input, @Helvetosaur. I’m from the PC world, where most software behaves like this and it’s taken for granted. I haven’t worked in a team environment before on Mac.

Not sure how I feel about having to create a temporary copy in order to be able to view a file without modifying it on disk…

Is there a feature request logged for correcting the behavior of “Revert Changes” as well? If not, I’ll have to log one.

Thanks all for outlining the workflow and problems with the current setup. I think I understand the issue you are having @ola_strandberg. I’m sorry the work-arounds for this are awkward.

@Helvetosaur is correct, cross-platform file-locking is something we will be working “soon-ish.” Fixing this will be important for the Worksession feature. Whatever fix we institute, we will keep the workflow you have described in mind… I doubt it is uncommon. That said, the fix might not be as straightforward as we’d like and - until we dive in further - it’s difficult to say what will (and won’t) be possible in the 5.x release cycle for Rhino for Mac. The reason for this is that it is highly unlikely that Rhino 5 for Windows will change to accommodate. (The V6 release cycle is another issue, entirely).

If I’m understanding the behavior you would like to see, I’m not sure that there is much we can do. As @rhinorudi says, this is OS X provided behavior. So if you wish to log an issue, it’ll probably have to be with Apple. That said, if we can manage to get the file-locking working properly cross-platform, we should be able to give you very clear warnings so that you don’t lose work.

the way i understand it to work is more like–
open a previously saved file from dropbox and draw a line (or something to put it in an edited state)… after a few minutes, it will autosave and the save is going to the .3dm you have opened… dropbox notices the change and syncs… the file itself is continuously changing on mac… likewise, dropbox is continuously syncing… then when you do a Revert, it does a final save/sync with all of this sessions actions undone.

there are a few problematic things that can be brought up about this but from a consumer pov, i suppose one major thing to realize is if you’re using tethered data on one or more of the computers… if you’re modeling while tethered, you may be unknowingly using cellular data… disconnect after getting latest version and reconnect upon saving so it only syncs that one time.

i think dropbox (and others) are aware of problems in cloud type collaborations or multi machine workflows… here’s a thread from a couple of weeks ago which relates to this thread

something that will sometimes happen to me which i haven’t really looked into is i’ll end up with new files in dropbox named such as:
HCouture_GamingTable_Shop (Jeff’s MacBook Pro’s conflicted copy 2015-08-19).3dm

instead of looking into the exact cause of that or even figuring out what state the files are in when it happens… i just try to prevent having the same file opened on two computers at once… as well as try to be a bit more clean with the workflow (not leaving files open when i leave the desktop etc (which is how this has typically happened for me… model on the desktop… go somewhere… open the file on the laptop… the file is now open on two computers…) so i just try to prevent that.

something new i just noticed is if you right-click a file in that’s inside your dropbox folder, you’ll now have an option “View previous versions”… (dropbox 3.10.7 / el capitan… not sure when this first began though.)

choose that and you’ll go to a web page:

click on one of those versions and the file downloads (as in- to your downloads folder)… you’ll have your current version untouched in the dropbox folder and a new file in downloads at whichever state it was in at the time of sync you choose.

that’s pretty neat though i’m not sure if i can make use of it other than file recovery if needed.

but, you can look at my versions log and see how often a file may change and/or sync to dropbox throughout a session…
you can also see i did some stuff prior to lunch which brought the file up to 13MB (probably copying a portion of the model then manipulating it on the side…) …after lunch, the file was still open… did a Revert and the final sync of the day went back to the 9MB size… or- this is (possibly) a clearer example showing that even though a Revert was done during a dropbox session, it doesn’t mean the file was never being modified and/or causing conflicts like ola is saying.