INFO: Error Messages from Analyze Tool of Visual SourceSafe

Last reviewed: February 11, 1998
Article ID: Q152807

The information in this article applies to:
  • Microsoft Visual SourceSafe, 32-bit, for Windows, versions 4.0, 5.0

SUMMARY

This article reviews common error messages and status messages produced by the Analyze tool for Visual SourceSafe 4.0 and 5.0. The messages documented in this article are returned by the Analyze tool that can be obtained from the Microsoft download sites. For more information on how to obtain and use the Analyze tool, please refer to the following article in the Microsoft Knowledge Base:

   ARTICLE ID: Q139566
   TITLE     : SAMPLE: Analyze5.exe Utility for Visual SourceSafe

The messages reported by the Analyze tool are echoed to the screen. They are also written to the DATA\BACKUP\Analyze.log file by default.

MORE INFORMATION

Following is a list of the most common messages you receive when you run the Analyze tool, with or without using the -F option, to repair a database. The messages that appear when you want to get a verbose listing (-V switch) are not documented here. This list is not comprehensive. Please contact Microsoft Technical Support if you receive an error not documented here.

How Visual SourceSafe Stores Files and Projects

In order to understand some of the messages below, it is crucial to understand how Visual SourceSafe stores files and projects. There are two files created for each file and each project in Visual SourceSafe and they are stored in a subdirectory of the DATA directory. The name of the subdirectory is the same as the first character of the Visual SourceSafe file name, also known as the physical file name. One of the two files is called the "Log" file. It does not have an extension. This is where Visual SourceSafe information and differences between one version of the file and the next are stored. The other file is called the "Data" or "Tip" file. It has an extension of either .A or .B, and it stores the most recent version of the file or the project.

Following is a method to identify the name of a file from the Visual SourceSafe physical file:

Call the following command to create a file named Physical.txt that indicates all the files that have not been deleted and are not corrupted in the Visual SourceSafe database:

   SS physical $/ -r -ophysical.txt

Search Physical.txt to find the file name you are looking for. If you are searching a specific file name (MyFile.txt) in the Physical.txt file, be sure to scan the whole file as there may be multiple instances of a file.

LIST OF MESSAGES

  1. The CRC for data file "File Name" (Physical Data File Name) does not match the stored CRC. The file may be corrupt. The file was last checked in on "Date; Time" by user "User Name" in project "Project name."

    Example:

    The CRC for data file "MyFile.txt" (YBGAAAAA.a) does not match the stored CRC. The file may be corrupt. The file was last checked in on "10/15/96; 11:26a" by user "Guest" in project "$/MyProject."

    Cause:

    This message does not usually include the last sentence about the last checked-in date and time. When Analyze returns this message, older versions of the file may be lost if the error is not corrected right away. This message occurs because the log file records the Cyclical Redundancy Check (CRC) for the last updated copy of the file and the last recorded CRC does not match the current CRC.

    Resolution:

    To fix the error, first verify that the name of the copy in the working directory of the user who last checked in the file matches the name of the Physical Data File. If it does, make sure that the "Check in unchanged files" option in the General Tab of the Options menu is set to "Check In." Then perform a Checkout on the file and Check it back in. This will correct the stored CRC.

  2. Creating a new nameset, or long filename information, for the file <File Name>.

    Example:

    Creating a new nameset, or long filename information, for the file MyFile.txt.

    Cause:

    Analyze is reporting that it is attempting to fix the long file information for this file.

  3. The data file for "File Name (Physical Data File Name)" was not found.

    Example:

    The data file for "EQUATES.INC" (aiaaaaaa.b) was not found.

    Cause:

    Visual SourceSafe keeps the last copy of each file in the database as an individual file (.A or .B), also known as the data file. Analyze noticed that the data file corresponding to the filename is missing from the database. It knows whether to look for a .A or a .B file based on an entry in the log file (AIAAAAAA). This error is usually caused by the data file being marked as "read-only" or by a network or server problem during file creation.

    Steps to Resolve:

    If the data file mentioned in the error message is marked "read-only," reset the "read-only" attribute so the file is writable.

    If <File Name> is a project, you can run Analyze -F <Path to Data> to fix it.

    If <File Name> is a file, there is no easy way to solve this error. The best alternative is to access the history of the file and identify the user who last checked in the file. You can then obtain the latest version of that file from the user's working directory. Copy the file from the physical data file name (with the .A or .B extension, as specified in the error message) to the correct subdirectory in the database. For example, a file that starts with the letter A should be stored in the A directory. Be sure to rename the file as part of the copy process.

    If you have multiple instances of this file in different projects in your database, you need to determine which project stores this file. See directions above for creating an output file. Search in the physical output file for the Physical Data File Name without the extension. In the example above, this would be aiaaaaaa. If you move up in the file from occurrence of aiaaaaaa you will see the project name that includes the file.

  4. Database analysis in progress.

    Cause:

    This message is informational only and reports that the Analyze process has started.

  5. Encountered a bad CRC in <File Name>; record type <Record Header Type>.

    Example:

    Encountered a bad CRC in Status.dat; record type SH.

    Cause:

    Each file has a header. Analyze reads it and computes the CRC for the data that is currently there. If it does not match the CRC in the header, this message is displayed. The key information is the File Name and Record Header Type. If this data is unrecognizable, then the header is also bad.

    This error usually only occurs once at the beginning of the Log file. It occurs most often for users who are upgrading from SourceSafe 3.x. The Status.dat file that is used to store the file (whether it is checked out or not) is corrupted.

    Steps to Resolve:

    If this message appears for the Status.dat file, running Analyze -F <Path to Data> usually fixes the problem. However, for other files, the impact of this corruption is that this record is lost. Depending on the type of the record, Analyze may ignore it, fix it, or just remove it. If the File Name and Record Header Type are recognizable, running Analyze -F might recover the file.

  6. The file "<Physical Log File Name including path>" appears to be corrupt. Unable to read the format or header.

    Example:

    The file "f:\vss\data\O\ORLAAAAA" appears to be corrupt. Unable to read the format or header.

    Cause:

    Files in Visual SourceSafe have format and header records to identify the file. One or both of these is corrupted. This error is very serious because it usually indicates that the rest of the Log file is damaged.

    Steps to Resolve:

    The best solution is to retrieve the file from backup.

    If no backups are available and the file is a project, delete the files from the DATA\?\ directory. Be sure to delete the file with the extension of .a or .b and the file with no extension. Then run Analyze -F <Path to Data> to clean up the links. All files that were in that project are likely to be lost.

    If it is a file, then make a copy of the data file (the one with the extension of .a or .b), and then delete the files from the DATA\?\ directory. Delete the file with the extension of .a or .b and the file with no extension, and then rename the .a or .b file to its real name. Finally, add the file back into Visual SourceSafe. You will have to Identify the file. See directions for identifying a file at the beginning of this article.

  7. File "<Physical Log File Name including path>" is not the correct SourceSafe version.

    Example:

    File "f:\vss\data\H\HACKAAAA" is not the correct Visual SourceSafe version.

    Cause:

    Each physical log file maintains its database version. The setup process of Visual SourceSafe runs a utility called Ddconv on the database. Ddconv runs through the database and converts files to the current version. This message occurs when the file was not converted to the correct version because someone was using SourceSafe during the conversion, the file was read-only at that time, or the file was damaged in the earlier version of SourceSafe and Ddconv couldn't recognize it.

    Steps to Resolve:

    If there was just a lock on the file, you can safely run Ddconv against the database and it will convert this file. The syntax to run Ddconv is as follows:

          DDCONV <Path to Data>
    

    Any corruption in the file or the project will need to be fixed before Ddconv can convert the file. Unfortunately, because the rest of the database has already been upgraded to a Visual SourceSafe 4.0 format, it is hard to determine what that corruption is. You can recover your SourceSafe 3.x database and run the 3.x version of the Analyze tool for SourceSafe 3.x on the 3.x data to determine the corruption. Once fixed, you can run Ddconv on the data again.

    If you do not need the file or the project, you can move it, along with its corresponding data file (.A or .B), out of the DATA subdirectory. Then call Analyze with the -F option to clean up any links to the file. See the directions at the beginning of this article to download the new version of the Analyze tool.

  8. The file <File Name> was branched from <Physical Log File Name> that is missing a branch reference. A reference will be added.

    Example:

    The file CBLIST.ASM was branched from NNAAAAAA that is missing a branch reference. A reference will be added.

    Cause:

    The branch parent does not have a reference to this file. Analyze is reporting that it is adding a reference of that branch to the original file.

  9. The file <File Name> was branched from <Physical Log File Name> that is now corrupted and the early versions will be inaccessible.

    Example:

    The file MyFile.txt was branched from SOLAAAAA which is now corrupted and the early versions will be inaccessible.

    Cause:

    This message informs you that versions of the file before it was branched are damaged because of a corruption in the branch parent file.

    Steps to Resolve:

    This message is informational only, and there is nothing you can do for the file in <File Name>. Ideally you would fix the corruption in the branch parent, the physical log file name in the message. There is probably another message in the Analyze.log file about the corruption in the branched from file.

  10. Found a reference to an invalid rights block.

    Cause:

    There is corruption in the Rights.dat file. This is the file that stores project security information. This error can usually be fixed by running the new Analyze with the -F switch.

  11. The Header information in the rights system is corrupt.

    Cause:

    There is corruption in the Rights.dat file. This is the file that stores project security information.

    Steps to Resolve:

    You can fix this problem by running the new Analyze with the -F switch.

  12. Incompatible database version.

    Cause:

    The Version.dat file contains the wrong information.

    Steps to Resolve:

    This error usually occurs when a user is upgrading from SourceSafe 3.x to Visual SourceSafe. It occurs because of a problem in the conversion process. The problem is usually documented in the Ddcerr.log file that is located in the DATA directory.

    For more information about the messages in this file and how to resolve them, please see the following article in the Microsoft Knowledge Base:

    ARTICLE ID: Q153823

       TITLE     : DDConv Messages of Visual SourceSafe
    
       When the problem is cleared up, running the Ddconv utility again
       usually updates the Version.dat file. The syntax for calling the
       Ddconv utility is:
    
          DDCONV <Path to Data>
    
    

  13. The item <File Name> has an extra parent relationship that will be removed.

    Example:

    The item MyFile.txt has an extra parent relationship that will be removed.

    Cause:

    This is an informational message indicating that the file listed has a parent that is not needed. The Analyze tool is removing the extra parent record.

  14. The nameset information for <File Name> is corrupt.

    Example:

    The nameset information for Myfile.txt is corrupt.

    Cause:

    There is corruption in the Names.dat file for the listed file name. The Names.dat file is where long file and project information is stored.

    Steps to Resolve:

    Up to 33 characters can be recovered by running Analyze with the -F switch.

  15. No parent(s) or branch(es) were found for file "<Physical Log File Name>."

    Example:

    No parent(s) or branch(es) were found for file "BRGAAAAA."

    Cause:

    This means that the file currently has no parent or branch records and the Analyze utility will place the file on the delete list. If this file is branched from another file that has not been deleted, it will not be removed from the database and therefore this message will continue to appear. This is normal SourceSafe behavior. This message is not an error in your source code. This message should have been a verbose logging message, but was improperly classified as a regular message.

    Steps to Resolve:

    Usually running Analyze with the -F and the -D switches will fix the references or destroy these files, if appropriate. However, please note that this will not remove all occurrences of this message.

  16. No parent project for subproject file "<Physical Log File Name>."

    Example:

    No parent project for subproject file "ABBAAAAA."

    Cause:

    This error means that this project was not automatically removed when the parent project was deleted or that the parent project has somehow been lost.

    Steps to Resolve:

    This error is usually fixed by running Analyze -F <Path to Data>. The tool either reconstructs the parent or removes the sub project if it is no longer needed.

  17. Project log "<Project Physical Name>" has a <Log Type> record for item "<File Name|Project Name>," but that item was or was not found in the project.

    Example:

    Project log "DGEAAAAA" has a create record for item "MyFile.txt," but that item wasn't found in the project.

    Cause:

    Analyze takes the log records from a project and the current list of children records in the project and plays the log records backwards until it gets to the beginning of the list of log records. The list of children should be empty corresponding to the creation of the project. This error indicates that there is a mismatch between the history of the project and its content. This is just an internal check.

    Steps to Resolve:

    Depending on the nature of the error in the log, this message might be corrected by running Analyze -F. This is not a dangerous error and you can ignore it. This message almost always appears with the next message.

  18. The project contents as rebuilt from the log "<Physical Log File Name>" does not match the projects actual contents.

    Example:

    The project contents as rebuilt from the log "DGEAAAAA" does not match the project actual contents.

    Cause:

    This message almost always appears after one or more of the message documented above. It occurs because there is a mismatch between the history and the log files. This is an internal check.

    Steps to Resolve:

    This message may or may not be fixed by Analyze -F, depending on the problem in the log. This is not a dangerous error and you can ignore it.

  19. A rights setting mismatch was found.

    Cause:

    The Rights.dat file, which stores project security information, contains an invalid reference.

    Steps to Resolve:

    You can usually fix this error by calling the Analyze utility with the -F switch.

  20. There is a diff chain size mismatch in file "File Name"(Physical Log File Name)" at version # (versions earlier than that version can no longer be retrieved from the database).

    Example:

    There is a diff chain size mismatch in file "MyFile.txt" (FYIAAAAA) at version 12 (versions earlier than that version can no longer be retrieved from the database).

    Cause:

    This message is an error and means that versions older than the one specified can't be retrieved. This is usually caused by an error in a log entry record, that causes the difference chain (or delta) to be unusable to properly regenerate older versions of the file.

    Steps to Resolve:

    The only resolution is to retrieve the file (FYIAAAAA and FYIAAAAA.a (or .b)) from backup.

  21. There is a version sequence mismatch in the log file for "<File name>" (<Physical Log File Name>).

    Example:

    There is a version sequence mismatch in the log file for "MyFile.txt" (FISHAAAA).

    Cause:

    There is a missing log entry in the file. This behavior usually occurs when the Analyze utility has found a damaged log entry and removed it. If this log entry is a label, no older versions of a file are lost. If Analyze removed an Update log entry, then older versions of the file might be lost.

    Steps to Resolve:

    If you need the missing version of the file, you can retrieve it from backup if you know when the corruption occurred and recover from before that time. This may mean that later versions are lost.

  22. Unable to create the filemapping for the database <path to DATA subdirectory>.

    Example:

    Unable to create the filemapping for the database c:\vss\data.

    Cause:

    A file name in the DATA directory is greater than the largest allowable file name. This usually occurs when a non-SourceSafe file is written to the DATA directory.

    Steps to Resolve:

    Scan the DATA subdirectory to remove the entry that is not a SourceSafe file.

  23. Unable to open project <Path Used as Analyze Parameter>\a\aaaaaaaa Continue?

    Example:

    Unable to open project f:\vss\a\aaaaaaaa Continue?

    Cause:

    Analyze cannot find the main project in the database. This error usually occurs because the path to the project is incorrect when you call Analyze.

    Steps to Resolve:

    Run Analyze and ensure you are pointing to the correct location of the SourceSafe database.

  24. The file <filename> contained one or more badly formed physical file names.

    Example:

    The file bqeaaaaa contained one or more badly formed physical file names.

    Cause:

    A badly formed filename means that an internal record has a physical filename in the improper case. For example, BQEAAAAA => bqeaaaaa is a harmless message.

    Steps to Resolve:

    Run Analyze with the -f switch.

  25. The error "The count of the children in the header does not match the count of children on disk. The count will be adjusted." is not a critical error.

    Cause:

    Within every project header, a number is kept that is indicative of the number of children associated with that project. One of the many things that Analyze does as it scans through the database is to count the children files associated with that project. If the number that Analyze counts does not match the count in the header then the error is returned.

    Steps to Resolve:

    Analyze -F should fix this by synchronizing the actual number of children with the number that is in the header.

  26. "Found a 'COMMENT' record in file <file name such as 'jogaaaaa'> at position 33818" errors are usually caused by orphaned comments.

    Cause:

    Visual SourceSafe sequentially writes data to its log files. An example of how you might have extraneous information would be if you add a file and supply a comment at the time of the Add. Later, go to Properties for that file and change the comment. Now both comments are stored in the data file. However, you will never be able to access the first comment from SourceSafe again.

    NOTE: The number 33818 used in the error example above indicates that the comment starts at bit 33818 from the beginning of the file.

    Steps to Resolve:

    Analyze -c should fix this error. The -c switch allows Analyze to compress free space that may exist in data files and thereby release disk space. However, this process is considerably slower and should not be run on a frequent basis. So, if you run Analyze with -c and it discovers two comments for a file, it rewrites the data file and leaves out the older comment. While this switch can reduce the size of the database in some cases, it usually does not make a significant difference.

  27. "Found a 'DIFF' record in file <file name such as 'jogaaaaa'> at position 33818".

    Cause:

    Analyze returns this error because a DIFF chain has been found but cannot be associated with a log record in the file in which it was found.

    A DIFF chain is made up of DIFF chunks that are ADD, CHANGE, or REMOVE records. For example, if a file that contains only "Hello world" is checked out and modified by adding "Bye world" and then checked back in that ADD creates a DIFF chain.

    The number 33818 used in the error example above indicates that the DIFF chain starts at position 33818 from the beginning of the file.

    Steps to Resolve:

    Analyze -c may fix this error. The -c switch allows Analyze to compress unused comments that may exist in log files and thereby release disk space. However, this process is considerably slower and should not be run on a frequent basis. So, if you run Analyze with -c and it discovers two comments for a file, it rewrites the data file and leaves out the older comment. While this switch can reduce the size of the database in some cases, it usually does not make a significant difference.

REFERENCES

For more information about the switches used with Analyze, please see the following article in the Microsoft Knowledge Base:

   ARTICLE ID: Q139566
   TITLE     : SAMPLE: Analyze5.Exe Utility for Visual SourceSafe


Additional query words: mapping
Keywords : ssdb vbwin vss kberrmsg
Version : WINNT:4.0,5.0;
Platform : NT WINDOWS
Issue type : kbinfo


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: February 11, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.