How to: Find and Repair Data Corruption
Visual SourceSafe ships with the ANALYZE utility, which checks all the files in the Visual SourceSafe Data directory for corruption or disconnected links. It often repairs these problems with proper switch settings. For details of the tool, see ANALYZE Utility.
.gif) |
|---|
Note Microsoft occasionally updates the ANALYZE tool to include more checking or to improve performance. For the latest version of ANALYZE, visit the Microsoft Visual SourceSafe Web site located at https://msdn.microsoft.com/ssafe/default.asp. |
The types of problems that ANALYZE can correct include:
Parent-child mismatch. Possible situations include those in which a parent (project) assumes it has a child (file or subproject) but the child disagrees; a child assumes it has a parent but the parent disagrees; or child and parent don't reference each other, but the child counts are off.
Corrupt database files. Files that can contain corrupted data include Names.dat, which stores file names longer than 34 characters; Rights.dat, storing relationships between users and project rights; Status.dat, containing checkout status information for files; Um.dat, which stores all users of a Visual SourceSafe database; and Version.dat, storing the Visual SourceSafe version.
Removal of unused items from the database.
|
|---|
Note Because ANALYZE is so thorough, it can be slow to run. The amount of delay depends on the content the database, for example, the total number of files; the amount of sharing and branching being used; and the structure of the database. To increase the speed of the tool, minimize the number of options you specify for ANALYZE. |
Use ANALYZE as frequently as practical for your site. Once a week is recommended, but at a minimum, you should run the tool once a month. Due to the amount of file I/O required to run ANALYZE, you can dramatically improve performance by running the tool locally on the server, instead of across the network. You should also ensure that no virus protection software is currently running.
For best performance, all users should log out of Visual SourceSafe before you run ANALYZE. If you use the -F option to repair problems, users must log off. To minimize the impact on your users, you can restore the regular archive of your production database to another location and run ANALYZE on that copy. You might also create a duplicate online copy of your Visual SourceSafe database using the ROBOCOPY utility from the Windows NT Resource Kit. This utility copies all the files in a folder and subfolders. However, if a file is in use, it will retry the copy instead of just failing. If you detect problems in analysis of the backup database that need to be resolved, you can then lock out users from the production database while making any necessary fixes. If ANALYZE returns no errors, you do not need to interrupt user connections.
To analyze your database:
ANALYZE rebuilds the Rights.dat file so that you can lose information about rights for individual users. Back up this file before running the tool.
Each time you run ANALYZE, you should create a list of all items in the database. This list is useful in determining which logical file name is related to an error based on the file name (for example, Abcaaaaa.a) for which the error is reported. To create the physical list, at the command prompt, type:
ss Physical $/ -R –O@PHYSICAL.TXTThe first analysis pass should always locate problems before trying to fix them. At the command prompt, type:
analyze –V4 <database path>Check the results window and the Analyze.bad file in the Backup directory to find out which files have errors.
Close the results window.
If you have sufficient disk space, rename the Backup directory so that you can keep it throughout the analysis. You can keep the original directory, but it must be empty for the next analysis pass.
If errors are reported from the first pass, run ANALYZE again in fix mode to correct them. At the command prompt, type:
analyze -F –V4 <database path>Check the results window and the Analyze.bad file in the Backup directory to find out if errors remain.
Close the results window.
Rename the Backup directory resulting from this pass. You can keep the original directory, but it must be empty for the next analysis pass.
If there are "Found a DIFF" and "Found a COMMENT" errors that you want removed, run another pass of ANALYZE as shown below. Before running the tool, which includes a compress option, it is very important to ensure that you have enough disk space available.
analyze -F -C –V4 <database path>Upon checking the results window and the Analyze.bad file now, you should find no more errors.
Close the results window.
You might rename the Backup directory from the last analysis pass, so that you will have a record of the entire analysis operation for future troubleshooting.
If you need to rebuild the Rights.dat, Status.dat, and Names.dat files, rename or delete the files you want rebuilt.
Now run ANALYZE again, using the following command line entry:
analyze -FClose the results window and rename the Backup directory if desired, or empty it.
Note that ANALYZE has created the Names.dat file with the spaces in long file names appearing as underscores. Rename the file in Visual SourceSafe Explorer.
Copy the rights of your users from the file copy you made at the beginning of the procedure into the rebuilt Rights.dat file. Alternatively, reset user's rights as described in How to: Assign Project Rights.