BUG - autosave with dropbox

[mortenengel]

Autosave slows stalls the computer down on the last two versions of Rhino.

I have had to switch it off as it stalls the computer every few minutes.

Awful to work with.

Maybe it’s only related to files saved on dropbox?

Or is it a general problem.

Please help a.s.a.p.

[JimCarruthers]

Yeah this is why I save everything local-first and the online sync is a “backup” instead of “saving to online folders,” I never have issues like this.

We’re obviously going to need a lot more information, obviously this is not something thousands of other people are experiencing.

[Japhy]

You can turn off writing the local temp file to save some bandwidth

[mortenengel]

Ok. Will try this.

But what does this actually mean?

[Japhy]

When WriteLocalTempFileWhenSaving is enabled (True):

1. Rhino writes the file to a temporary location on your local drive first
2. Once the write is complete, it renames/moves this temp file to the final destination
3. This uses an “atomic rename” operation, which is safer and more reliable

When WriteLocalTempFileWhenSaving is disabled (False):

1. Rhino writes directly to the final destination location
2. The file is written in chunks/segments over the network

The Trade-off

• Local drives: Keep it ON for safer atomic writes that protect against corruption
• Network/Dropbox: Turn it OFF to avoid cross-filesystem rename failures, even though it means writing directly (which is less protected against interruptions but actually works reliably on those locations)

The root issue is that cloud sync services and network shares handle file operations differently than local filesystems , making the atomic rename approach problematic when the temp file and destination are on different storage systems.

[mortenengel]

Thanks for explaining.

The issue wasn’t there before.

Only with the last two versions of Rhino.

Did you change something, that could be reverted?

[Japhy]

There are a lot of potential factors here. Ideally we can narrow it down to specific version that was working different for you. Let me know what releases you would like to try and i will send links via PM.

[nathanletwory (Nathan 'jesterKing' Letwory)]

For all we know it could have been an update to Dropbox as well.

[mortenengel]

Hmm. Yes. I didn’t take note of that.

But it’s still a major issue.

Rhino is virtually unusable with autosave.

And at the same time highly unstable. Lot’s of crashes. So I am saving often.

And I am worried this is filling up the file cache on OS X as I am also having weird out of disk space situations om my MAC….

Lot’s of trouble it’s causing.

[wim (Wim Dekeyser)]

Hej Morten -

@mortenengel

So I am saving often.

And I am worried this is filling up the file cache on OS X as I am also having weird out of disk space situations om my MAC….

I take it that you have not disabled the macOS Versioning feature for Rhino?
If you haven’t (for Rhino 8, that requires running a test command. The option was exposed in the UI of the WIP last week), macOS is saving all the changes for you and you shouldn’t have to save on top of that.

@mortenengel

Hmm. Yes. I didn’t take note of that.

Do you automatically install new final SR versions or do you manually download an updated version once in a while?
-wim

[mortenengel]

This is still causing massive problems for me.

I get out of memory where Rhino completely freezes.

And my hard drive is filling up In the folder called .DocumentRevisionsV100.

Is this folder used by Rhino for autosave?

How can I purge my rhino files of the horrible ‘time machine’ backups??

It’s a real nightmare working with Rhino last several months.