If I open a rhino file, it creates .RHL file, which locks the file. So when I open the same file in another rhino instance, it opens as a readonly file, as expected. But what happens is, when I close the first Rhino instance, the RHL file disappears, which allows me to save the file from the second instance (which was opened as read-only).
This is risky because if we accidentally click ‘Save’ on the readonly file, the file might get overwritten. Could this be a bug?
Hi Darryl - yeah… it is not a bug - in that it is designed behavior… this was done to fix another problem in dealing with files on synced drives. But it is also not ideal, as you point out - essentially there are two incompatible situations, is what I gathered from the developers, and both cannot win…
The Rhino instance having the file opened in read-only mode should have an option to watch the file system for a (potential) change of the file-lock, and notify the user if he wants to reload the file.
On network drives the notification could be optional, or a "checkbox “stop checking for file changes” leaving it to the user to decide if it’s a potential problem or not (often it isn’t).
If I understand the problem, that is really, really bad. Luckily we only have one licence of R6 at the moment, but the boss is pushing to upgrade all of us to R6. I will push back until this is sorted or clarified.
- User 1 opens file
- User 2 opens file read only
- User 1 modifies file and saves
- User 1 closes file
- User 2 saves file and over-writes User 1 changes
- User 1 work is lost
Have I got it right?
@JohnM - FYI, the comments above… not sure what the right way out is.
@Ncik yes this is exactly the issue.
G’day @pascal, is this getting any attention?
We regularly open files as read only and the concequences of this bug fill me with dread. Read only files should never, ever, ever revert to read and write…ever! I don’t know of any other software that behaves like this. The correct procedure is if Save is pressed with the file as read only you are presented with a SaveAs dialog, at which point if the user overwrites the original then that’s their own fault.
Please clarify the issue if I’m overreacting or have missed the point. We only have one R6 licence so I can’t test. I can’t believe this isn’t blowing up here or in the wild, it’s far bigger than dodgy fillets (which are perfectly fine imo), so perhaps I have missed the point.
This Issue is fixed with 6.28.
Thank you for your help and sorry for the delay!