Saving Failure

I’ve recently been getting an occasional error while trying to save files. It’s been happening every couple days or so, the error message says that it has failed because “The temporary file could not be renamed”. If I try to save it a second time it gives me the typical read-only dialog like if you open the same file twice and try to save the second one. I then have to ‘save as’ and use a different file name. (Incremental save works pretty quickly for this)

If I browse to the directory in windows the .tmp file is there along side the original file and I can delete it. The other original file can’t be deleted until the Rhino session is closed. It gives a file in use error from windows saying it is open in compute.geometry even though that file has been saved with a different name and therefore should no longer be in use.

A couple notes for what they’re worth:
-These files are using sharepoint. Although sharepoint sucks, it doesn’t really seem like it’s at the heart of the issue.
-Grasshopper… I’m using a few sizable definitions (500-1500 components) that were originally created in V5, then updated for V6 and again in V7. I wonder if these were re-built from the ground up in the current version of GH if that would help any, if they weren’t so huge I would have tried that already. I’ve been having a bunch of Rhino UI problems that I’m still trying to isolate & replicate that I believe only happen while using these GH definitions. This is really a separate topic which I will start once I have a better understanding of what’s actually going on, I just thought I’d mention it.
-I’m using the latest service release 7.4 but this may have been happening in 7.3, I wasn’t on that version for very long. I don’t recall it ever happening before that.
-GH plugins being used are Human, Human UI, FabTools, Elefront, Mallard and Bowerbird. There are a bunch more plugins installed/loaded but I’m fairly certain those listed are the only ones with components that are actively being used.

Any help would be greatly appreciated, thanks!

1 Like

Hello - You can try SR5 - there are some changes to Save that could, possibly, affect this. you can get SR5 by opening Options > ‘Updates and Statistics’ and setting ‘Update frequency’ to ‘Service release candidate’.


Done. I’ll keep you posted. Thanks!

It continued happening, I was able to isolate it to my desktop by testing everything on my laptop. I bit the bullet and completely removed Rhino, all plugins, and any trace of anything related that I could possibly find, started fresh, installed the plugins that I use regularly and everything seems okay so far. :crossed_fingers:

My guess is that it was probably just some lingering effects from a few years of upgrading, adding/removing plugins etc. etc., far too much to be worth the time to dig into. As an aside, I’ve had the UI issue again already that I had mentioned before, I’ll continue to try to isolate that one and start a new thread about it later.

Thanks for the help! Cheers!

Hi Ainsley - I see - thanks for the update. Are you saying this happened when saving to the desktop as well as other locations? I am not really sure how SharePoint works -is it a syncing thing similar to DropBox etc?


Same problem here.
Saving to a network location in my NAS.
I’m running Windows 10 (up to date) and Rhino 7 SR5 2021-3-9
Thanks in advance!


Hi Pascal. Any news on this issue?
The problem here keeps manifesting.

Hi there, it also happens to me since the last update to 7.5.21068.13001, on 2021-03-09
I also have Windows 10 (up to date)

I open a file, make a few changes, click the Save icon and this appears:

followed by this:

in my machine Rhino is always ran as admin, and my D drive is not the same one on which Rhino is installed
the only (maybe not even relevant) changes in the last days are the Rhino update to last candidate and Hops installation through PackageManager

after the error, if I click again on the Save icon, it pops-up the browser windows to chose the place where to save the file, as if it was a brand new drawing
→ if I chose the very same file location and name (to overwrite the old one) it asks me confirmation for overwriting an existing file, then the two above pup-up messages appear again stating the file is open in read-only

the only solution is to save with a new file name

1 Like

Exactly the same happens to me.
Same pop ups.

Also in my case I’m running latest Service Release Candidate on Windows 10.

Also in my case only happens after last SRCs.

And, of course, same solution.

1 Like

@pascal, sorry to bother, I just wanted to add more details

because the only way to save a opened file is to give it a new name, I started adding _1 _2 _3 at the end of the original file names

30 minutes ago I opened the version_3 file, made some changes, pressed save, error window popped up as previously described, saved as new file version_4

now I’m trying to just open the old version_3 and this popped up:

it behaves as if the files that Rhino opens (in my case: version_3) is set to Read_only, impossible to overwrite, and weirdly the file keeps being in Read_only mode as long as that instance of Rhino is running

I closed Rhino and ran it again: the version_3 file is opened regularly

I also give my confirmation the problem arises if and only if Grasshopper somehow deals with the opened Rhino file: I worked on Version_3 for a good 60 minutes and was able to save by overwriting the same file dozen of times

as soon as I opened GH and internalized one geometry of Version_3 then the Rhino file was in Read_only and the same message windows started popping up again

I’m trying to uninstall Hops (just because it is the only thing that is changed in Rhino in the last week, apart from the R5 update) and will update if anything changes

[edit] by uninstalling Hops from packagemanager the problem disappeared

My case seems different: I have currently no plugins installed via Packagemanager, but the “save problem” keeps manifesting. Was not happening before last RC install.

Hope to find a solution.

. Gianpietro

@stevebaer - just fyi, on the Hops aspect…
added - RH-63292 Hops: blocks file saving
Dunno if that is really for you or not…


@gian - does saving to the desktop work as expected?


Mh…I’ll give it a try and let you know.

@inno Rhino is telling you the truth here, and it’s not something we can control. It appears that your operating system or drive has that file opened for exclusive write by some other process. This, in turn, makes it impossible for Rhino to save over the top of it.

This might be a bit geeky, but to figure out which process has the file open, you’ll probably need to use Microsoft’s Process Explorer as described in the first answer here:

Please let me know what you discover!

1 Like

Though it looks like you discovered already that it’s Rhino via Hops.

1 Like

thank you for this,
it might easily be that Hops and my Read_only issue was just a coincidence and they are not related…
the thing is, since I have uninstalled Hops (with PackageManager) I am not able to reproduce the error anymore, everything works smoothly again
so if it would be somehow useful for me to reinstall Hops and do some testing to provide you any useful data, I’d be really happy to do that! otherwise I’ll keep it not installed until next releases and keep my Rhino Save more stable :slight_smile:

It’s up to you. I’ll see if @stevebaer has any idea why or how Hops could keep a document open in Rhino, or make it appear read-only.

@inno if you have the time to test this out, I would really appreciate it.

Please reinstall Hops, restart your computer and see if you can get the read only issue again. If Hops is to blame, it would help me to understand the steps you took to get this read only bug. I don’t currently know how this could be caused by Hops, so I am not working on any sort of fix.


I have found the same Read-Only bug since I started using Hops.

I just uninstalled Hops and the problem stopped.

The error messages I’ve been getting include “unable to save temporary file” every time, if that’s any help.