Local Save Does Not Work - Follow Up

 After speaking with an Autodesk developer we now know that our issue is related to past eTransmit use. Revit mistakenly retained a flag it uses to mark that file as such.

If we can successfully use Synchronize with Central and we get that message when we use Save then the correct response to the warning dialog is the top option: "Save this model as a central model in its current location - Revit will remove this message and allow users to create local copies of the model."

Remember, the message is accurate for files that have been created via eTransmit too. In our situation the files were working fine on BIM 360 but they retained the flag that should have been removed when they were added to the cloud.

Info Added 6/4/2021: The warning is triggered ONLY in the following scenario:

The warning is triggered ONLY in the following scenario: The model has been transmitted and then upload to BIM 360 from Revit using the option “Work temporarily”.

To eliminate this warning for future project, please make sure you choose “Save as a central model in its new location” when uploading the models to BIM 360 from Revit.

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.

Create New Local is Disabled

I've written about this in the past, like THIS ONE. Today I noticed another circumstance where the option is disabled even though it shouldn't be. When we browse to open a project we can click on a file listed among the contents of a folder. If we do that then Create New Local is enabled and checked by default. At least that's true if other circumstances are not preventing it, like those described in my other post.

What I saw today is that if I choose to type some of the file name in the file name field Windows will supply me with a list of file names that begin with those letters, cool Windows behavior. If I select the correct file using that list then Create New Local sleeps through the effort and fails to become enabled.

Want to see it happen?

Create a Local File - How Often

Every time...

I no longer reuse Local Files. My attitude and habits have changed a little over the years. I wrote this POST in 2008 and then THIS on in 2011. I've touched on the subject many times within the context of other workset related posts.

I treat my Local File as ephemeral...temporary... I make use of the Open File option Create New Local each and every time I start working on a project again; yes even if I just stopped working earlier to have lunch or join a conference call.

Revit 2017 - Enabling Worksharing

The process for enabling worksets has changed with this release because Collaboration for Revit (C4R) has been incorporated into Revit directly. This allows someone to subscribe and begin using it quicker. They might even be able to do so without any (or much) EyeTee intervention.

The first evidence that there is something different is on the Collaborate ribbon tab; there is a Collaborate button next to the disabled Worksets button. There is a new Communicate panel too.

In the past enabling worksets began with clicking on the Worksets button but now we start by clicking on Collaborate. This takes us to the fork in the road necessary to permit sharing the project via A360/C4R whether we are able to use it or not, just in case. If the file hasn't been saved before clicking Collaborate we get a message asking us to do that.

Then the Collaborate dialog appears asking us to specify which method of sharing the project we need; Collaborate within your network or Collaborate using A360.

When we choose Collaborate within your network Revit enables and creates two User-Created Worksets called Shared Levels and Grids and Workset1 (like in the past) but it doesn't open the Worksets dialog (like it used to). This allows us just to get on with our work using the Active Workset (Workset1 by default). If we need to create additional worksets then we'll find the Workset button is enabled, just click it to open it (Workset dialog, as in the past.

The Communicator button is tied to using C4R. It is a separate window (dialog) that can display information about your project team activity, if you're sharing the project using A360. Imagine concepts from Worksharing Monitor combined with Instant Messaging features and that's what you've got. FWIW, it used to be able to dock inside the Revit UI but it doesn't do that now. If you've got two or more monitors you'll probably prefer it on one of them instead anyway. This is what it looks like if I'm not logged into A360 and not using it to share this project.

At some point we'll need to Save the file and like in the past we'll be warned that this is the first time we've done that since we enabled worksets; click Yes.

Remember, if you'd like to set the default Open option to Specify remember to use Save As instead of Save. You only get a chance to do that with Save As. This allows us to choose which Worksets Revit should load before it opens the project entirely. This can have a significant impact on how long it takes to load a project.

At this point we are still working in the Central File, which isn't practical to share the project nor is it advisable. I can determine that by looking at the Save icon on the Quick Access Toolbar (QAT), it is disabled and the Synchronize and Modify Settings button next to it is enabled. The project's file name listed on the Title Bar doesn't include my user name either. By the way, we need to SwC to relinquish our ownership of the User-Created worksets properly. The only way to do that is to use SwC (Synchronize and Modify Settings), via the dialog that appears. The Synchronize Now button does NOT do that.

Now that worksets are enabled and relinquished we need to close the project so the team can get started by creating their Local Files. When I browse to the Central File to start work I need to make sure that Create New Local is enabled and double check the Open option is assigned to Specify.

Remember doing so will cause this dialog to appear before Revit begins opening the project further.

Okay, now get to work; in your Local File!

A Case for Worksets - Opening Linked Files

It is common to choose to avoid enabling Worksets when we don't need to let more than one person access our project at the same time. If we rely on using linked files then we can benefit from not avoiding them. For example, if you've ever wanted to open a linked file at the same time as the file you are currently working in you've seen this warning message.

Revit doesn't like opening a linked file in the same session, without unloading the link in the current model first, but it won't mind doing so if you open a second session of Revit. Revit uses separate memory allocation for each session. That means it isn't possible to use Copy to Clipboard with Paste Aligned when we are using two sessions. If you let Revit unload the link instead you won't see any changes in the host project until you save, close and reload the linked file. A good many users regard that cycle of steps to be annoying.

When we enable Worksets we have a Central File but work in a Local File. If all the project files we use have enabled Worksets then when we open any of the Linked Files we are creating a new Local File. Here's the tricky part...technically that's not the SAME file we Linked. The Linked File is (should be) based on the Central File (it's name and location)...the Central File is linked, not our Local File.

Yes this means you can now open a linked file in the same session of Revit. You can make changes in either file and use Synchronize and Modify Settings to store the changes in the Central File(s).

Now before you get too excited, you still have to use Reload on the Linked File that's been changed. That's not really any different than having another user making changes to the Linked File and having to use Reload to see their changes. It does make it easier to go back and forth between models quickly; eliminates the open/close part. Eventually you have to use Reload to see any changes regardless.

If you are a sole user and still intimidated by Worksets; just remember you only have to have one Workset for it to be enabled, for Revit to work. Revit creates two default Worksets for us to use (Shared Levels and Grids and Workset 1) but we don't have to be too concerned with assigning elements to any but Workset 1. That's assuming we don't really need Worksets for its fundamental purpose; allowing concurrent access to the same data by more than one person.

Something to consider if open/closing and unloading/reloading links is annoying.

Oh, I should mention that this starts to disintegrate if you are opening more than two files that are inter-related, linked into each other. For example, imagine a Host Model, Linked Model 01 and Linked Model 02. The Host Model has linked both of the linked models. If Linked Model 01 is also linked into Linked Model 02 and we then open both of them as well as the Host Model we will encounter this kind of message when we make changes to Linked Model 01 and then attempt to reload it in the Host Model.

The file in question is also present in the other open Linked Model and that is what Revit is objecting to. We'll also find that the file is unloaded automatically. We'll have to close the other file that it is visible in before we can successfully reload it. As such my habit is to limit my use of this technique to two open files at a time.

Be Careful Creating a Central File in 2015

A thread at Autodesk's Revit User Community Forum caught my attention yesterday. It seemed as though the culprit was something I've written about before, that user's were accessing the project via different shared resource paths. After digging in a bit deeper it turns out the issue, or at least an issue, is that Revit 2015 is more sensitive to how we navigate to the a shared resource.

This is what happens when I browse to a shared folder via My Computer and click on the Drive letter S:

This is what I expected to see (disregard the project name, I was experimenting with being logged in and out of A360 too):

A clue or warning you can watch for is what Revit displays at the top of the Save As dialog.

If you see the drive letter in the description then you'll likely end up with that as your path. I believe you should only see the folder the central file will be in if you are mapped correctly.

It is my habit to always use Synchronize and Modify Settings before closing the Central File, after creating it. As such I can see what the path that Revit captured is. When I notice that it is wrong, like the first image above, I can fix it, get the correct UNC path recognized instead by taking these steps (see the image that follows too):

• Close the Central File (after noticing the wrong path reference)
• Create a local file (before any other users start to work)
• Use Synchronize with Central
• Click Browse and click Browse again in the next dialog box that opens
• Select the Central File by browsing to it via the shared resource path instead, type it in directly if necessary.
• Click Open
• Click OK (the correct UNC path should appear now)
• Click OK (The path is fixed)

If you are creating a central file be very careful about how you browse to the project folder. Verify you have the correct path established before letting users begin working on the project.

Cannot Create a Local File

I read about a couple items in a thread at RFO that could affect creating a Local File in addition to to what I've mentioned in the past.

Revit appends our username to the local file it creates for us. That addition could cause a local file's name to exceed the maximum number of characters, which is 260 (file name and path). That's 256 plus the four characters associated with the drive letter, for example C:\ (space/null after the back slash).

The other possibility mentioned is having Auto Off-line Access enabled.

Gosh computers and software are fussy buggers!

Local File Error on Open

Have you run into this error message before?

One possible reason is that the folder you are storing local files is running out of allowable space. A folder can have restrictions placed on it. If so Revit can't properly create the local file in a folder that has hit its quota.

When we create a new local file we can often avoid this if we use the option to Overwrite the existing local file versus the Append Timestamp option. Chances are there are just a great many older local files hanging around in the folder.

Revit Worksets Error - Element has been Deleted

David Baldacchino shared an issue with me that he's run into recently.

Here's how he described the issue.

As a standard, we create our central files with the option "Specify" so users are prompted to pick which workset to open/close when creating a local file. If a user is in a local RVT 2013 file AND THEN another user tries to open a detached copy in Revit 2014 to upgrade it (whether doing this directly from the central file or a local file), the Revit 2013 user/s will start getting errors stating that elements were deleted from the central file when they try to edit. They are also locked out of touching anything until the upgrade process finishes. This issue does not happen if the Specify option is not used. This behavior is not expected and undesirable.

Sounds like it can be avoided, if the file needs to be upgraded, by keeping people out of the active project file. I'm not sure I'd want someone to upgrade a project that someone is actively adding new work to with the previous release. Regardless if it occurs it explains why the error message Elements have been deleted appears.

Watch for Users Overwriting a Central File

Last week I wrote a post about the Create New Local option being disabled and what that can mean. In response Harry of Boost Your BIM wrote an example macro to catch us when we try to overwrite a central file with our local file. Can't help but wonder why Revit doesn't catch this sort of transaction already? I don't know if Harry plans to share this macro. He may offer it as part of his new Part 2 API Class at Udemy?

Create New Local Option is Disabled

When the Create New Local is disabled one of these four culprits are usually to blame:

• The file does not use worksets (occasionally to blame)
• The network connection/resource is busy, or disconnected (likely culprit)
• Someone is creating a local at the same moment (less often, but happens)
• Opening a file created in a newer version of Revit (less often) [added per a comment]
• File is a Local file (user copied a local over a central)
• The network path at each workstation is not the same as each other (very likely culprit)

This is an earlier post about this issue, it's called Creating a Local File - Clue to a Problem.

These are some other Local File posts.
Local Files - How, How Often and Where
Local Files
Working in the Central File
Why Does my Filename include the word Central?
Local Files - How Often

Local File Location

Can a Local File and Central File be in the same folder? Sure.

Revit doesn't really care if a local and central file are in the same folder, as long as Revit doesn't think they are the same file. I do it all the time when I'm doing testing at home. As long as I let Revit create my local file with a unique name it doesn't care where the files are. In a real office setting it doesn't make any sense to put a central file on a workstation. It also doesn't make any sense to put Local files on a server either.

Usually EyeTee wants nothing important on workstation so they can schedule regular backups. The reality is they are getting a backup of the project, the Central File. Local files are nothing more than a "working copy" of the project and they ARE meant to be perishable. If you heed the advice on this blog you are already creating a new local every day or, like me, every time you start work on a project.

Create New Local Disabled

Usually the culprit is the network path (previous post). If it is intermittent, as in it worked a few minutes ago but now it isn't, it can be something else. It is probably file access, meaning Synchronization with Central by others or someone opening their own local file at the same time.

I find the create new local option is disabled occasionally when there are a lot of other users active. If I select the file and the option is disabled I click on another central to see if it is network related. My thinking is if it does it for several central files then somethings wrong with "me". If I wait a few seconds or minutes I find that clicking on the file again will allow Revit another "look" at the file and the option "wakes up".

It may just be busy people and activity between locals and the central.

Working in the Central File

We are supposed to work in local files. Occasionally people will fire up Revit and end up working in the central file instead. These days it is more deliberate because they have to un-check the Create New Local option to do so.

Revit has been tweaked over the years to deal with central file editing. I've read claims in a couple books recently that working in a central file prevents other users from using Synchronize with Central (SwC). It isn't true in my experience. If I'm working in a local file I can use SwC as much as I need. The person working in the central file on the other hand will be forced to create a local file when they try to use SwC. They'll get this message.

I can work in a central file as long as necessary, as long as nobody else is working on the project in local files too. Isolation is fine, collaboration is where the conflict arises. We encounter the message above when a change has been made via a local file while the central file is being edited. While someone is editing the central file a local file user has been able to add or alter an element and then use SwC. When the local file user completes a SwC and the person working in the central file attempts to use SwC the central file editor will get this message (remember Save is disabled in a Central File).

The message also explains how to resolve the situation, just Save As to save the file with another name, which turns it into a local file. Now SwC will work.

There are some legitimate reasons to work in the central file, just do it in isolation.

Can't Alter Create New Local Selection

Said another way, the "Create New Local" option is disabled (gray'd out).

I've written about this in the past. My post focused on the network relationship between local and central files. It boils down to the central file being created by a user whose computer is mapped to the server and project folder in one manner and the person who can't manipulate the "Create New Local" option is mapped differently. As long as this condition exists this "rogue" person won't be able to synchronize their work, sadness ensues.

Daryl wrote about this occurring because of different software versions and Luke echoed his post later. While this certainly can and does happen we just need to take care that we don't actually save a file that has been opened in a newer version of Revit unless everyone is prepared to upgrade their project files too (assuming a large team all using Revit).

It's been my experience that the network path conflict is the more frequent culprit, or at least the one with the greatest "danger". Remember if you don't know why the option isn't available to you, check with someone to make sure you can continue safely. Said another way, "Be afraid, be very afraid".

Local Files - How Often?

Various versions and years have intervened between now and when I wrote these earlier posts.

• Worksets - Take Me to the Library
• Central File in Four Easy Steps
• Local Files - How, How Often and Where?
• Which One STC or STC
• Why a Local File?
• Workset Terminology - Quick Reference
• Revit Worksets 2010 - Local Files
• Stand-Alone File - Central File - How can I Tell?

I recently responded to a query about how often local files ought to be made with this:

I think that new local files should be created each morning and used throughout the day. The next morning should repeat the process. The current solution implemented in Revit supports this thinking by allowing people to easily create a new local (by default) and append a time/date stamp to previous local files when creating a fresh one each morning. For a little history (my own perspective):

My original reasoning for new locals each day years ago was never about corruption (the query suggested that new local files were necessary due to frequent corruption) but about faster loading and not having to remember to use Reload Latest or wait for that either. Opening a central and doing Save As back then meant waiting twice for the files to open (still does now technically). Going back a little further even (for me) the practice of copying the file and pasting it instead of "open/save as" was about "faster" too.

Sporadic team involvement meant inconsistent local file "sell by dates". Mine was current but "Joe’s" is three days old when he opens it because he’s been out of the office for the last two days. If he starts in that file he’s got two day's data to "Reload Latest". If he creates a new local he’s in sync within the window of other people working "today", between when they started and he arrived and started...pretty close to in sync.

File corruption that I encountered from time to time "went away" when people made new locals each day too. Happy coincidence, definitely. Necessary? I don’t know, but it worked to resolve those situations. The corruption probably had more to do with inconsistent participation and "sell by dates" out of alignment than the central/local file arrangement itself. In the end, it was easier to "eat an apple a day" (make a new local) than to wait and see if the issue would arise again.

Since the addition of the new local file option I’ve abandoned other "custom" local file techniques but I still create a new local each day, it isn’t any slower than opening an existing local file and I don’t have to remember to use Reload Latest. I am getting older and my memory isn’t what I remember it to be.

Now where did I put my cane and glasses?

Creating a Local File - Clue to a Problem

The Revit Clinic confirmed an issue I've been seeing for some time now. I thought I wrote about it in the past but it seems that I haven't. If you click on a central file (2010 and 2011) Revit detects this and checks the Create New Local option.

If you find this option disabled (gray'd out) then that's a clue that something is wrong. The situation I've observed and the clinic's first listed problem is that Revit thinks that your computer is finding the central using a different path than other members of the team that have also created local files. In my case I usually find that someone is showing a path that reflects the Network Neighborhood path instead of a formal Drive Letter mapping. In a couple of other cases I've encountered a specific IP address instead.

A post yesterday at The Revit Clinic confirmed that these issues are indeed a problem for Revit when we intend to create a local file. If you find the Create Local File option disabled, STOP. Get some help to fix your path before you find yourself unable to Synchronize with Central.

There are two other explanations offered in The Revit Clinic's post; worksharing isn't enabled and a corrupt central file/thumbnail issue. I've also observed that the so called corrupt central file is occasionally really a local file. In this situation someone saved their local file in the folder where the central file was and chose to overwrite the file. The unfortunate consequence of this is that nobody else can synchronize with central because it isn't a central file anymore. Take care, it's dangerous out there folks.

Revit Worksets 2010 - Local Files

They revised the process that we use to make local files with 2010. It is easier and a bit safer, so to speak. I say safer because I don't like users getting in the habit of opening central files at all. The new process does let them click on the central file but Revit is smarter about it and uses a default choice Make a Local File instead. Local files are saved in the location you define by using the Options dialog and the File Locations tab, finally specifying the Default Path for User Files as shown here:

I created a short video demonstrating the steps to create a local file. You can listen and watch here.

Revit 2010 - Local Files

I've been writing about Worksets for a long time now. Revit 2010 provides a new process for creating Local Files (for projects using Worksets). When you attempt to open a project in 2010 Revit detects whether it is a central, local or stand-alone project file.

Central File - Option to create a local file is checked
Local File - Option to create a local file is disabled
Stand-alone File - Option to create a local file is disabled


Revit will place the local file in the location defined here, Default Path for User Files

Revit will append the username to the file initially. If you attempt to create another local file and Revit finds another with the same name it offers this dialog.
As you can see it gives you an opportunity to either overwrite the existing or append a time stamp to the file instead.

For what it is worth...a grain of salt perhaps...a little background, from my perspective.

The formal recommendation from Autodesk has always been to create local files by using File menu > Open, open the the Central File followed by using File menu > Save As to save your Local File (literally a copy of the Central File) on your local PC. This was both time consuming (two open sequences essentially) and "dangerous" (user's routinely/habitually opening the Central File).

To counter this process what we started doing with local files (essentially some version of copy/paste/rename) a long long time ago now has turned into a "cottage industry" of local file creation/management techniques and tools/software. Autodesk has distilled it into a "simple" and better process than what was before, which wasn't really an appropriate process at all.

I use three fundamental criteria for local files and process.

Use methods that ensure users do NOT...

...develop a habit of opening central files
...store their local files anywhere they please
...use the same local file endlessly

As far as the software is concerned where the local file is located is technically immaterial. In my opinion, as long as it is on the local pc and in a folder that isn't only accessible to one user then it's "good".

I completely understand and can relate to the motivation to define where they go and how they go but we don't have to keep these files for the long term so in a sense some of us are getting a bit carried away.

This new Autodesk solution meets each of my long standing criteria more reliably than before, though honestly, anything would since it didn't at all before. It will be easier to teach users what to do. I'd prefer that they didn't have to browse to "touch" the central file at all but as long as they don't un-check the option Create new local they'll be fine.

Ideally Worksets and all its sundry baggage of language and rules should continue to become less intrusive, less confusing and as efficient as possible. This is a good step in this direction. For the next release the developers would do well to provide a few more options for folder locations and file naming rules.