Monday, May 15, 2017

Insert From File and a Worksharing File

I bumped into a subtle conflict this evening. I created a new file from a stock template. I then used Insert from File > Insert Views from File to acquire a few drafting views. When I closed this new project and decided to open the file the harvested drafting views are stored in this message appeared.


Keep in mind that no files were actually open at the moment. I was looking at the Recent Files list yet when I attempted to create a new local file for the project I just used Insert From File on the message popped up. This means that the file is technically still open in RAM as far as Revit is concerned, it's just not open for me to interact with.

I had to exit Revit so it could relinquish its hold on the file before I could start Revit up again to get back to work.

3 comments:

Matthew Gonzalez said...

I've seen this many times in 2017 (though not lately) except it wasn't a "local vs central" thing it was the same old "can't open a file that is linked into an open project" message. Problem being that absolutely nothing was open. I also had to completely quit Revit to resolve the issue.

David Lindsey said...

I have seen a similar thing recently when creating new workshared files for various disciplines for a large project I have going on. After linking the various discipline models and closing my new model, sometimes I get this message when attempting to open one of the models I just linked to a file that is now closed. My only option is to close Revit and re-open.

Adrian Esdaile said...

Yes... It's slightly naughty behavior by Revit; and it's also the reason why it is so easy to corrupt a Central File by clicking the 'red X' Windows UI close button, then click 'why, yes, Revit, of course I wanted to Save my work' button.

I've watched the resulting disaster step-by-step using Process Explorer / Disc Explorer / Wireshark. It's like watch a train wreck in slow motion.

Revit hands off all of it's data in one giant blob to the Windows file transport system, which dutifully says 'Ok, Revit, I'll start saving this to the storage resource the same way you asked me to open it - chunk by chunk'. Revit says 'yeah, whatevs, goto go, BYYYYEEEEEE!' and shuts. Meanwhile the Windows transport system has been sending data at the maximum packet rate of your network, and turns back to Revit and says 'OK, I've sent the first 8192Kb, could I have the next... hello? helllooo? Where did you go Revit? Hello? Oh, OK, the file must have only been 8192kb then. kthnxbai'.

Thats non-technical speak for why your 4.67Gb Central File is now 8,192kb.

It's also why there's a huge chunk of (4.67GB - 8192kb) allocated RAM with a great big 'I BELONG TO REVIT' on it. For even more laughs, quickly reopen Revit, open a small file, then start Dynamo. Keerrrrraaaashhhhhhh! Yes, Dynamo finds the previously allocated wreckage. Garbage Collection? I can't even code in C++ and even I've heard of it.

Seriously, grab Process Explorer and laugh yourself silly at how horrifically bad Revit is at managing data; and how horrifically dangerously it accesses Remote Storage - lots of little tiny chunks and tens of thousands of reads to a single giant file, instead of just open-and-parse-in-memory. I think Revit tries more than 3,000 separate reads to the smallest possible RVT file, an empty project of about 7Mb - what on earth is it doing?

Come on, Autodesk; Revit is just a MASSIVE Relational Database at heart, it's about time it starts using proper, proven, industry-supported methods for storing and accessing it's database. Like using SQL, or one of the plenty of other quicker, safer, more robust methods. JSON even! The 'lock-file-on-disc' method that Central Files use is laughably mid-1990's; it's dangerous, error prone and unreliable.