Overview

Came across a new error we had never seen before the other day, and there is no (or incredibly hard to find) documentation by Autodesk on solutions/cause. 

Update 01

Spoke with Autodesk about this issue specifically. Autodesk stated specifically this was most likely due to a user double clicking into the file and accidentally opening an ‘unconnected local’ or some other mishap that doesn’t allow the user to create a local as normal. We tried numerous times to verify this but we were unable to. Additionally, after verifying the users were opening as local, the problem still persisted even with this. So in conclusion… no confirmation. However, since we followed all these steps, the problem has seemed to generally disappear. 

“The file filename_user.rvt already exists. If you replace it, you will lose all of its backup versions. Do you want to replace the existing file?

The Problem

First Reaction

Naturally our first reaction was to immediately stop the user from syncing and cancel out this issue. The way that this error is worded makes it sound like you are replacing a central, working in a central, or doing something funky that you should be doing.

After multiple rounds of googling, we couldn’t figure out what Autodesk thinks about the issue, but we were able to solve it without losing any work.

What Is Actually Going On?

We were able to verify the user wasn’t working in the central, noone on the team was doing anything they shouldn’t have been doing worksharing wise, and in general there was no syncing central/local issues happening when looking deeper.

What we came to realize is that this more than likely is a backup specific issue, with the automatic backups created by Revit. This is specifically for worksharing files and the folder that is automatically created for the central file. (not to be confused with the local backups or your local copy). For our particular file, it was 750mb and the number of backups was set to be 999. Truthfully we have never run into this issue before, but it seems that there is some sort of incremental auto-numbering or file generation that may run into issues eventually with the backup number set this high on larger files.

• Even this is a bit peculiar because we have several other files with similar constraints and feel we would have run into this before.

Solution

1. Immediately have that user cancel and just hold tight, get some coffee
2. Perform incremental and methodical syncs of all other users in the file. Have them verify that their syncs complete. They do not need to exit the file, we just want to make sure they sync all their latest work to the central.
3. At this point the central is the latest except for the user who encountered the error. For safety, we detached and created a manual archive of this snapshot. Always be safe.
4. Once your backup is complete, go back to your server location of the central file, and delete your auto general [filename]_backup folder directory. This most likely will delete a bit, but then will eventually say something is in use and it cant get past it. That is fine, we just want to delete absolutely everything we can.
5. At this point you should be able to have the user who was having issues sync again, without the error popping up.

Follow-up Steps

While that should have fixed the issue for the team to keep working without any work lost, we obviously want to fix this long term.

1. End of day or on the weekend sometime, first verify that everyone is out of the central and no one is working in that file.
2. Make an archive of the central
3. Detach your central and then delete your old central, along with the backups folder. At this point in time (unlike earlier) you should be able to delete the entire backup folder.
4. Save As to make a new central, but this time set something more appropriate like 99 or 499 depending on project size.
   1. If you have automatic backups set on your server or are very routine about archiving manually, you could set this very low.

Further Thoughts

We of course are taking our best guess at this issue. While the solution solved it, it’s an assumption. Do you have more knowledge on this issue? Shoot us an email and let us know so we can add/update the page and share with others.