So I have an ongoing issue with files being flagged as read only. Save as does not clear the issue … I think there needs to be a feature that removed read only locks if the source file is no longer read only in windows… here are the details
I use One drive as a cloud solution to give me a single save location for several computers… One drive does employ a local cache and synch mechanic, which means that occasionally it will start synching the file, and if you happen to try and save at that moment you will lock the file as read only… Typically this will mean if you check one drive it will be in the middle of the file synch…
So you’d think if you wait out the file synch and then resave it would be fine … but this is not the case it’s still locked.
Save as and selecting the same file name does not work either …
Thus the only thing you can do is save the file under a different name, then at that point you can do a save as and select the original name and the lock is now gone and you can save again …
I get the point of the lock - eg windows has the resource marked as read only because it is in use (synching to the cloud) … but to me I’d rather not have to save as a different name (which uses more space) I also think i understand that Rhino creates a lock file to trigger the lock, and I suppose i could hunt that down and manually delete it?
I think a more informative error message that informs you to check if the file is in use, synching or marked as read only and had a option to recheck the file to see if it’s still in use and clears the lock if it is could be a real win.
You are going to have occasional problems like this using a synched storage locations.
You can always browse to the folder using File Explorer and del the old RHL lock file.
cool to know i could just delete the lock file… might it be possible to add a button to the error to re-try that checks the file state again and removes the (lock) file if it’s no longer read only?
I would not want that.
The whole point is to NEVER have 2 people editing the same file and overwriting each others changes.
The problem is trying to use a synched folder as the active editing folder.
A safer approach would be to edit the files locally, then copy them to a shared stored location.
That has it’s own gotchas, but then everything will work as designed.
fair - however it’s sort of legacy thinking… Compare this approach to apps like office, or Adobe CS … these apps now support active saving via cloud… This works well in the cloud driven world of 2022… In the modern enterprise users are never supposed to save anything locally as it creates both security issues, and data retention issues as local files can more easily be lost. For me - i need access to my latest work on the road without needing to manually copy things to a cloud every time i leave the office. Virtualization, and remote work is bigger then ever and i expect my work environment to be omnipresent- eg it’s there wherever I am.
So that said local “works” better so One drive works “locally” most of the time anyways (for speed of local file access versus over the net it has a local copy) then periodically checks the local file and reupdates the cloud version… it’s at this moment the quirk happens… eg one drive marks the file as read only so it can synch and that trips rhino saying the file is read only and creates a lock file. If the hypothetical button checks again and the file were still really read only it would simply re-pop the error… but if the file is no longer marked as read only the lock file is simply a nuisance. For me I’m a single user eco system.
I follow the idea that synch errors get more complicated when multi users are involved but i think that sort of error handling is sorta covered already. I use a Surface studio as my home office workstation, and a surface pro as my travel workstation … IF i have a file open on my laptop and then I edit the file on my home studio PC, it creates a save with the PC name that generated it… eg filenamePCNAMEINCAPS … I appreciate the diligence in protecting the multi user environment as eventually I’d love to expand to being a multiuser studio.
Super appreciate the conversation - I can delete the lock file instead of swearing like a salor and saving the file with another name then saving it back … I do hope Rhino can find a way to be more cloud file friendly in the future
