Help: Saving toolbar on dropbox causes error message

Hi guys, I have a toolbar on dropbox that throws an error every day.
(@wim, @pascal? )

image

If I pause dropbox it works fine.
BUT if I close Rhino and get this error then I can’t pause Dropbox and choose “Try again” so any changes I forgot so save manually are lost.

Are there anything you can do?

EDIT: I also get this error IF dropbox is syncing and I try to save the toolbar in the toolbarmanager.
But then of course I can pause and try again.

Hi Jorgen - I am not too optimistic, but I will ask the master - @JohnM - is there any remedy when saving RUIs to cloud-synced folders?

Jorgen, just a thought, but It might be as well to SaveAs first, to get something on disk that you can retrieve, then SaveAs again to the original name that you wanted.

-Pascal

Hi Pascal, this is a toolbar I use every day, so the file is not new, but Rhino want’s to save it every day when I close Rhino. (And I update the tools often too, so saving it manually is a weekly routine)

I need it on dropbox for access on other computers too, but then it has a new name so I don’t get houndreds of conflict files there. (I tried that for a while)

The custom tools there are my bread and butter, so having them updated is important :slight_smile:

This didn’t use to be a problem before, but Dropbox did some changes some months ago (6, 8? can’t remember)

Thanks for taking a look.

It should be easy to replicate, but you would need to sync a big rhino file to dropbox over a slow line though… (Live in the woods, so that’s the downside of that I guess :slight_smile: )

I’m guessing it is a problem with drop box locking the file while synchronizing causing the toolbar code to fail. The RUI system writes a temporary file in the same folder as the RUI, if successful it renames the existing RUI RUI.BAK then renames the temp file RUI. My guess is DropBox is detecting the new file and syncing it before it can get renamed. I would recommend using a local version of the RUI on a daily basis and backing it up to DropBox when changes are made. The current system was not really designed to siamotainously share RUI files across several machines.

Hm, but why does it lock it? I can sve multiple rhino files at the same time if I close multiple instances. It only happens to the toolbars.
And saving a copy locally and only using dropbox for backup is a step backwards, so that won’t do it unfortunately. But thanks though.

Update, I get the error every time I open and close Rhino, even if don’t open a file.

So this is not related to dropbox being occupied with uploads.

Can you please try to duplicate the issue?

Hi Jorgen - the error you see is the same RUI related one, correct?

-Pascal

1 Like

Hi John, I don’t think we’ve met. And sorry if our first message interaction might come across as combative. Please don’t take my feedback personally. I just want to broaden your perspective here of what a massive fail this is on the part of McNeel. I’ll do that by giving you my perspective as a user, buyer, business owner, and manager of a team of several users, most of use having more than one machine.

This is a problem with Rhino not being able to adapt to a highly popular, if not universal, file system of how people in 2020 gets work done.

Adobe had the same exact problem with locked temp files in Indesign. They obviously realized that it was unacceptable to have such problem with service that’s as important as internet connectivity or OS support. So they fixed it quickly, with a patch.

No other software has this problem with Dropbox. This is NOT a Dropbox problem, this is a McNeel problem.

I would not call it ‘current’ system then. I would call it a ‘very outdated’ system that has not evolved in the way we, your customers, have been changing the way we work to be more productive. It has not evolved in sooooooo many ways, and we have been very patient about it. But this is just too much.

This is not about just supporting several machines, which of course you should! For example: have you surveyed what percentage of your customers do work in more than one machine? I bet is not an ignorable number.

In my company’s case we all work in Rhino for Windows. We use so much software, that we are benefactors, but also victims of the collective work of all the software developers of Microsoft, Nvidia, Dropbox, Adobe, Unreal, McNeel, Otoy, Chaosgroup, Ansys, Autodesk, etc, etc, etc. SO guess what? on average a Windows machine will stop working withing 9-12 months and we need to do a ‘reset and rebuild’. Sometimes that happens without warning, without giving us a a chance to go save what whas local. In fact the entire software stack of a Windows computers is just a very large, very time consuming to restore, temp file. So nothing gets saved locally, unless we mean to delete it permanetly.

in 2020, that’s unacceptable. In our jobs we got a ton of important things to keep track of. Please don’t underestimate the huge burden that such ‘simple tasks’ creates.

In Summary:

This is inexcusable and we need a fix. Soon.

Sincerely,

Gustavo

1 Like

Hi @JohnM I did some testing, and it seems the toolbar tool is the only program that causes this error.

If I have a toolbar on dropbox and dropbox is synced and I go and try and save it then this error comes immediately.

So I HAVE to pause dropbox whenver I want to save a toolbar…

Can you take a look at the code for Rhino, how that handles saving temp files and renaming and NOT causing this?

I am sure you can port that behaviour over.

Cheers!

Hi, can you add a RETRY button to this dialog?

I think the problem might be that saving as temp, deleting and renaming goes so fast that dropbox doesn’t have time to release the upload grip so it tosses an error.

image
(Yes, I tried to write retry with the mouse :wink: )

Or make Rhino wait a bit…
Maybe adding a sleep(1000) ( a second is no long wait for a program to close) might do the trick as well.

I also see that OneDrive does NOT have this problem, so obviously it is something with dropbox, but that only means that a workaround is in place.

As Gustavo said so well:

This has been logged as RH-59467

1 Like

bug_tracked

1 Like

fixed in Version 6 SR29
(6.29.20196.2061, 7/14/2020)
Commercial

1 Like

RH-59467 is fixed in the latest Service Release Candidate

1 Like

For your information:
Today I got this while both exporting and saving a file.
I’ll see if it continues.
image