Rhino mac crashed, when i reopened the file all the layers were still there but the file is completely empty. Please help!! 
In File > Revert, see if you can roll back to an earlier version.
Any luck?
No… its empty…
This happens to me if the server where the file is saved loses connection.
For some reasons all work is gone and I end up with the first version of the file. Even if I absolutely saved it while I was working.
After the server loses connection I am not able anymore to save the open file on the desktop nor anything else. I can only force quit Rhino and restart, but all work is gone. In Rhino 5 that worked fine. 6+7wip no chance.
The file was located in a OneDrive folder. Are you saying that the work is completely gone…?
I there is nothing in Revert, then yes.
I would STRONGLY recommend you work on your files in a normal local folder, then copy them to your cloud storage location after exiting to eliminate this risk.
I Found an older older version. Thank you!
I’m going to reiterate what John said for those of you that didn’t listen to him the first time.
**DO NOT WORK FROM A CLOUD DRIVE. **
WORK ON YOUR FILE LOCALLY AND SAVE A COPY TO CLOUD FOR BACKUP PURPOSES.
There are a number of reasons for this, the greatest of them is we cannot control anything that one drive, dropbox, google, or apple does with their file servers. we can however control what happens between rhino and your local drive.
I’ve been a pro modeler for close to 30 years. I have never lost a client file. EVER.
How? I work and save locally, at the end of my day I save a copy to a cloud drive AND have a backup system which backs up my local files(I use carbonite, but use whoever you want)
save, save elsewhere, then back it up.
@theoutside
I think you forgot that saving to a folder like Dropbox IS saving locally. The folder is just synced with the cloud server.
There are two issues here. Both are actually Rhino problems. One is saving to a synchronized folder (nobody else seems to have this problem), and the other is MacRhino’s use of Apple’s Versions, which seems hugely buggy based on the number of reports here - and not just to synced folders either…
2 Likes
that’s fair.
but for my own practice, I save to a local drive, then move a copy to cloud, and have a 2nd back up.
with thousands of models sold…I’ve never lost one…not a single one…ever.
So…yes, I agree cloud stuff should work, and we can argue about that until all the planets align, or you can guarantee you never lose work again, by protecting your most valuable asset (your work) with a simple, proven method of doing so.
Fair enough as well…
In my history of working with Rhino for Windows (since the beginning), I’ve never lost a model either. That being said, I do have two more comments though.
First, as concerns MacRhino, in order to really do as you say, there has to be an option not to use Apple’s Versions but instead to do your own saving and versioning manually - thus removing the dependence on an ‘automatic’ system that may be unreliable and putting the control squarely in the hands of the user, where it belongs.
Second, as concerns saving on ‘other than local’ drives… sometimes, there’s not really a choice. I worked in a university for many years and during that time our group had an immense project spanning more than 10 years with hundreds of files - some of them quite large. Most of the project was done in Rhino with lots of ‘accessory’ files such as .dxf’s, .stl’s and .pdfs.
As there were up to 5 people working on the project, it was out of the question to save files locally - we had to be sure that anyone opening a file had the latest version, and all the files needed to be accessible to all. If someone had saved locally but then ‘forgot’ to upload the latest version, it would have been a mess. So all the files were stored directly on our dedicated portion of the school server - which was constantly automatically backed up as well. Actually pretty much anything we did in our unit was stored on that server. We never had a problem with any kind of file/program - except Rhino.
We actually started out on Rhino 4 (in 2009), and in the course of the project moved to V5. It was then that problems started to happen. Occasionally a file already created would simply refuse to save the changes over the original - we would get a message that something failed and that the ‘temp’ file created by the Rhino save function could not overwrite the original. The only possibility was to SaveAs under a new name. As I said above, we never had any problems with anything else. Something changed about the file saving method between Rhino 4 and Rhino 5 that caused problems with some server setups. Nobody was ever able to determine what it was. That problem carried over into V6, I left the school before the WIP, so I don’t know if it is still there in V7.
The above problem is not exactly the same thing as the synced folder saving issue that some people have reported having with Dropbox, OneDrive and other synced folder apps, but I think is probably related somehow. There is something in the saving mechanism that trips up in some situations.
2 Likes