I’m testing rhino file locking to prepare for a shared folder environment.
Setup:
Set Rhino.Options.FileSettings.{EnableFileLocking,EnableFileLockingOpenWarning} options to True
Save a file test.3dm; close rhino
Create a test.rhl.3dm file with the following content:
SomeOtherUser SomeOtherPC Wednesday, July 10, 2019
Test:
Open test.3dm in one rhino instance
Open test.3dm in third rhino instance
Expected outcome:
BOTH rhino instances should present the file lock warning:
“[…]test.3dm” File is currently in use by user “SomeOtherUser” on computer “SomeOtherPC” File will be opened in read-only mode[…]
Experienced outcome:
First rhino instance opens the file with no warning
Second rhino instance opens the file with the expected warning
It displays the user and computer name as shown above/as specified in the crafted .rhl.
Comments/Analysis
The first Rhino instance does not alter the prexisting .rhl - but it ignores it. Is this by design? The second Rhino instance DOES obey the .rhl, and displays its stored user/pc data.
A possible rationale: Rhino looks for other rhino processes with a handle to the respective file, and if it finds none it assumes the .rhl was left over due to a crash.
Note however that this would cause a problem in a shared folder environment where the file is opened by a remote user. Without a warning, the file could be overwritten by the local user.
I do not discount the possibility of a spurious result caused by the artificial setup. However, in a shared folder environment (google drive or windows share) the local rhino instance would have access to only .rhl file, and should respect it.
Hello - this depends on what the shared folder means - if it is a Google Drive or Drop Box type arrangement the ‘cloud’ file will not be locked. The local copy of the file would be the one that is locked. If the folder is on a network and two users are opening the file, then the current system should work - I’m not sure why you created an rhl file by hand - what does that get you? Wouldn’t the test be to have Rhino create it as normal and see if the file is successfully locked?
If the folder is on a network and two users are opening the file, then the current system should work
if it is a Google Drive or Drop Box type arrangement the ‘cloud’ file will not be locked.
How would it work with a network folder, and why would it be advantageous for it to fail in the dropbox/drive case?
What I mean is:
How does rhino detect that the lock file was created by a remote user and not a local user, in the network folder case?
Does the local rhino instance query remote rhino instances or open file handles on the remote system?
Does rhino use different locking logic for network shared folders?
Would you agree that the drobbox/drive behavior you describe is a) currently broken b) easily fixed? Why would we want file locking to work across network folder but fail across dropbox/drive?
Dropbox/Drive are very important to many collaborative workflows today
many users/decision makers would find it surprising and costly for locks to work with shared folders, but fail with cloud drives
The following behavior would be a solution: check lockfile and block on presence of remote user/pc names
Wouldn’t the test be to have Rhino create it as normal and see if the file is successfully locked?
This test simulates rhl files created by cloud drives, and I believe this is the right test. In cloud storage the file is created by a storage agent running in userspace - essentially, the test creates a .rhl file as if googledrivesync.exe created it. I can confirm the test with Google Drive and a remote user, but I think you’ll agree that’s not necessary, because both tests would fail.
Some final questions
What is holding rhino back from supporting this use case?
Have you seen any workaround implemented (Such as an additional script that checks the lock file and warns the user)?
I very much need to get this working so that my team and I can collaborate and stop playing .3dm hockey over email. I hope you feel my quandary, thanks!
Hello - Rhino creates a rhl file when a file is opened - when you open a Drop Box file you do not open the one on the cloud, you open a copy that is on your drive. Another user opening the ‘same’ file opens a different copy on his or her drive. Each of these gets an rhl file and the one on the cloud does not - that is not something Rhino controls, it is a shortcoming of using these systems - the problem is one for DropBox to solve, not Rhino.
when you open a Drop Box file you do not open the one on the cloud, you open a copy that is on your drive
Agreed.
Another user opening the ‘same’ file opens a different copy on his or her drive.
I agree here too.
Each of these gets an rhl file and the one on the cloud does not
This is not correct. In google drive, the following happens:
User1 opens a file on pc1: pc1://myFile.3ds
This creates an rhl file on pc1: pc1://myFile.3ds.rhl
Google drive syncs this file to the cloud: google://myFile.3ds.rhl
User2’s google drive agent creates a copy of the rhl file on user2’ pc2: pc2://myFile.3ds.rhl
This is standard behavior for google drive, and at this point we expect:
If user2 opens the file, they’ll get a warning “File in use by user1”
However, what happens is that User2 opens their copy of myFile.3ds and there is no displayed warning.
To be clear, google drive syncs the .rhl file without issue, in a way that very similar to network drives. The unexpected behavior is caused when user2’s Rhino instance ignores user1’s .rhl file.
I believe that step 5 would work as expected in a network folder. How does rhino’s logic differ when it encounters an rhl file in a network drive as opposed to an ordinary folder?
But you should not expect this - the second user is not opening the same file, they are opening a local copy on their own hard drive which will get its own rhl file. On a network (not cloud) file there is no local copy and the same file on the network is being accessed by both users - that is why is works on a network and it does not work on a DropBox style system. See what I mean?
“But you should not expect this - the second user is not opening the same file, they are opening a local copy on their own hard drive which will get its own rhl file.”
This is incorrect. They are opening the copy on their harddrive, and it already has an rhl file. Morever, rhino won’t over-write that file. What happens is:
If user2 opens myFile.3ds.rhl, they will see user1’s information.
When user2 opens myFile.3ds.rhl once in rhino, their copy of myFile.3ds.rhl still has user1’s information
At that point, if they open myFile.3ds.rhl a second time, they will get the message "File in use by user1”
If your claim were correct, at step two user2 would see their own information in the rhl file.
Pascal, in your opinion it has to do with rhino’s behavior against file copies rather than network file resources. We agree here, but I believe this behavior breaks a valuable and important use case.
In other words, this behavior, reasonable as it may be, causes problems and can be fixed without much effort. In return, rhino would support a value adding use-case in today’s cloud-heavy environment.
Can you please agree with me here, and get me in contact with the next step in the bug triage process?
Hi Max - We can certainly agree that the rhl file locking does not work on cloud drives - it was not designed for that, and whether we call it broken, or overtaken by events, or whatever, it was not designed to deal with synced files - that is a different beast and I am not at all convinced that it is something that should or even can be fixed by individual software companies each for its own files.
That is correct, but irrelevant in this case, I’m afraid - User 2’s Rhino properly ignores this synced rhl file that is protecting a file on User 1’s machine, and opens the local file that is on User 2’s machine. The local rhl file is now replaced with one having User 2’s info since he has just opened the file. The rhl on User1’s machine is then synced and has User 2’s info as well. None of this does any good because the rhl files are referring to two different Rhino files. I believe what you are asking is for a lock on Rhino files of the same name, as distinct from the same file - that is a different kettle of fish and I would say, it likely has its own set of problems.
No, they get a message that the file is open by User 2 - as expected since the local file is indeed open on that machine.
Do you see that?
There are systems that purport to get around this, e.g.
The assumption that merely creating a rhl file locks a Rhino file is incorrect. The Rhino program also performs an OS operation to exclusively lock the rhl file and prevent access to it. If Rhino crashes, the OS automatically removes its lock from the rhl file and leaves the rhl file in place.
When Rhino opens a 3dm file and sees a rhl file, it asks the OS to lock the rhl file. If the OS cannot lock the rhl file, then the rhl file is valid and some other user has the 3dm file locked. If the OS can lock the existing rhl file, then Rhino knows that the rhl file is left over from a crash and can ignore it.
It is not possible to simulate Rhino file locking just by creating a rhl file. You must use multiple instances of Rhino to do this testing.