Restoring Corrupted Revit Files

Revised March 4, 2010

The information contained in this document is time-sensitive as the technology and system requirements
continually evolve. While D|C|CADD has made every attempt to validate all information, please verify and
refer to the official Autodesk System Requirements posted on http://www.autodesk.com. Unless otherwise
noted, all information applies only to the Autodesk 2010 versions.
Problem
A local file is detached from the central file, but retains ownership of elements, thus preventing access to
those elements by other users.
This problem occurs when a lapse occurs in the connection between the user and the central file location or
when users are not using the same version of Revit software. If the user continues to work after the
disconnection from the network and saves the local file, but cannot synchronize with central, the user will
not have relinquished ownership of that object. This may also happen when a file is opened with the
Detach from Central checkbox selected. The lack of communication between the local file and the central
file will allow another user to modify the same object(s) unknowingly. This conflicting data modification will
prevent the original (now disconnected) user from synchronizing with central, yet still shows the object as
borrowed.
Resolution
1. Ensure that everyone exits the Revit central and local files and has synchronized their local file with
the central file if possible.
2. Make copies of all folders and subfolders, including the individual backup folders of both the central
file and the local files and backup folders for each individual user. (Note: This step is a precaution in
case a backup restoration procedure is required; otherwise, project data could be lost.)
3. Audit the file(s). Open the central file or most recent local file, making sure to click on the Audit
checkbox and the Detach from Central checkbox in the File > Open dialog box. Auditing the file
will not fix the borrower/owner conflict, but it may fix other issues within the file. Detaching the file
will remove any previous locked owner/borrower relationships not previously resolved.

800.454.5499
www.dccadd.com
Austin
Dallas/Ft Worth
San Antonio

Revised: March 16, 2010

Page 2

4. Once the file has been audited and detached, open the Worksets dialogue (Collaborate tab >
Worksets). If you did not detach from central, you would notice worksets noted as owned or
borrowed by other people on the team, even though everyone is currently out of the project.
These columns should be cleared of all borrowers and owners. If not, repeat step 3, making sure to
select the Detach from Central checkbox. Close the worksets dialog box.
5. Go to the Save As dialogue (Application Button > Save As > Project) and select Options at the lower
right. Select "Make this a Central File after save" and then save the file. This will relocate this file to
a new location of your preference (consider a new and different location in order to preserve the
original files).
6. Create new local files for each user, and have each user synchronize with central.
7. Open the Worksets dialogue and confirm that no worksets are owned or borrowed. Close the
workset dialog box.
If an error persists after this procedure has been performed, the following procedure may be required.
Restore Backup
Proceed with the following steps only if necessary.
1. Close all related files by all users.
2. If all files/folders have not already been copied, as described in step 2 of the previous procedure, do
so at this time. After rolling back to previous saves, all work performed after that time is lost.
3. Click Collaborate > Restore Backup. Select the "backup" folder of the central file. (Note: If the
central file does not go back far enough or does not have the most recent content, local backup
folders can be selected as well. These may be different from and contain a larger time variation
than those of the central file. They will also vary user-to-user.)
4. Select the next-most-recent file to roll back to. Note that any comments made during the
Synchronize with Central process are displayed here to provide more information about what was
done during this save.
5. Repeat steps 5-7 of the procedure above.
Note: If the reason for the network disconnection is because a user's workstation has bad hard drive
sectors, is corrupt, or is defunct, a new computer must be renamed to the old computer's name and the
new username must be the same username used on the old computer. Both of these entries must match
the old workstations information identically so that Revit will recognize the users identity and allow the
user to open the file and relinquish objects and worksets. Once the worksets have been released, the
computer and user name can be reverted back to the previous names and identities through this same
process.