Hi @dan,
hm, good question, the corrupted file always occurs on NAS drive, but I wasn’t able to save it neither to NAS nor desktop. Just as if I was not saving at all. We had an IT guy in the office, so I will check whether something accidentally improves. If not, I will start a new thread.
I’m having this issue too with the latest version of V5.
I’ve ended up with many many versions of the same file because for some reason, Rhino started refusing to save.
It happened after I navigated to another file using finder so quicklook would have activated while the file was open.
Quitting and restarting rhino has been no help. Problem persists.
TL;DR: We’re still investigating. If you want to work around the problem, disable Previews in Finder when opening files from a network drive.
Just an update. I did a bit more investigation on this today to confirm what was already suspected. Somehow our Quicklook Finder Preview generator is at fault. It appears to be locking the file only when connected via smb to some types of file server (our Windows Server 2012 exhibits this problem).
As alluded to above by @msmr: In Finder, if previews are disabled - when you press command+shift+P - the lock is gone and the file opens normally.
I stumbled upon - and was able to reproduce - something similar in Adobe Photoshop using a .png file. (However, I was not able to reproduce the problem with Apple authored Keynote.app).
I still believe our Quicklook plugin is at fault here. I’ve been attempting to force our Quicklook plugin to release the file in a way that Windows Server 2012 will accept, but I’m not there yet (Quicklook plugins are difficult to debug).
Hi Dan,
I’m reasonably confident that it happens when connecting via AFP too. It’s surprisingly difficult to absolutely force macOS to connect over AFP when a server is offering both, but I’m pretty sure that’s how we generally connect.
Next time it happens to me I’ll double check.
Robin
I would not be surprised, but it would be good to double-check. Thanks!
I suspect - but don’t know for certain yet - that is bug is agnostic to protocol, but rather dependent on the server and drive itself.
That said, the fact that Keynote does not exhibit this leads me to suspect that we’re not closing and releasing our lock on the file in our Quicklook plugin. I’ve been experimenting with different methods of closing the 3dm file - after the thumbnail preview has been updated - that are more amenable to Windows Server 2012, but so far I haven’t had any luck.
The next thing I’m going to try is to spin up an macOS hosted network drive and map that and test. I’ll bet that will work just fine and not exhibit the bug.
I was surprised to find out I could reproduce this bug using smb: on a macOS hosted shared folder. I’m amending the bug title and description itself to reflect this:
RH-53222 3dm files shared via smb volumes open in read-only mode
If you want to leave previews activated, it should be enough to deselect the actual file and drag it to Rhinoceros.app in the dock, or right-click it an select “open with …”
1 Like