PRB: The Data File for <file> (<physical file>) Was Not Found

• Microsoft Visual SourceSafe, 16-bit and 32-bit, for Windows, versions 4.0, 4.0a
• Microsoft Visual SourceSafe, 32-bit, for Windows, version 5.0

SYMPTOMS

When running the Analyze utility against a SourceSafe database, the following message appears:

   The data file for <real file name > (<physical file name>) was
   not found

   The data file for "myfile.txt" (qusaaaaa.b) was not found.

CAUSE

Files under SourceSafe control are stored as a file pair: the data file and the log file. In this example, Analyze has found that a log file exists with no matching data file: there is a file qusaaaaa in the DATA\Q directory, but no matching qusaaaaa.b file.

NOTE: This article will use the file names in the example error message given above.

RESOLUTION

Your first step should always be to back up the entire DATA directory. You should also make sure you are using the most recent version of Analyze.exe. Please see the REFERENCES section of this article for more information.

There are three ways to resolve this error:

1. Delete qusaaaaa from the DATA/Q subdirectory.

2. Add a valid copy of qusaaaaa.b to the DATA/Q subdirectory.

3. Delete myfile.txt from the SourceSafe database, and then add it back.

Adding a valid copy of qusaaaaa.b can be done in two ways:

1. This is the better method. If a user has a local copy of myfile.txt that is identical to the last checked-in version, copy myfile.txt into the DATA\Q directory, and then rename the copy to qusaaaaa.b. It is important not to leave a file named myfile.txt in the data directory. You can see who last checked the file in by viewing its History. If that user has a local copy that has not been modified since the check in, this method will work.

   It is also possible that a user may have performed a "Get Latest Version" of myfile.txt (though there is no way of testing to see if this has happened) and has a local copy of the correct version of the file. If so, this method will also work, but you must remove the read-only flag of qusaaaaa.b after renaming it.

   This method assumes that the SourceSafe user or administrator knows whether the local version has been modified since the last Check Out or Get.

2. If you have a backup of the database, copy the backup version of the file pair into the DATA\Q subdirectory: qusaaaaa (the log file) and the corresponding data file that will have either a .a or .b extension. In this case, any changes made since the backup will be lost.

   If you do not have a backup or a correct version of the file, the only resolution is to delete myfile.txt from SourceSafe and add it back in. In this case, you will lose all history and branching information.

STATUS

This behavior is by design.

MORE INFORMATION

With Novell version 3.12 or later, on a Windows 95 machine using the Microsoft client for NetWare Networks (found under Control Panel .. Network .. Configuration), deleting a file from the SourceSafe database will delete only the data file, causing this error.

The above configuration is known to cause a problem. It has been seen in other configurations, though not consistently reproduced. For the purpose of this article, the configuration is not important because it is suggesting ways of resolving the error, regardless of the cause.

The following section provides some guidelines to help you determine whether you can delete the data file, or whether you need to add it back to the database:

1. Is there a single copy of myfile.txt, or multiple copies?

2. What project or projects contain myfile.txt?

3. If there are multiple copies, are they different files in different projects that happen to have the same name, or are they linked (has myfile.txt been shared or branched)?

4. Has every occurrence of myfile.txt been deleted from the database? If so, was it purged or destroyed?

You can answer the questions above using a combination of the following methods:

1. Issuing this command at the SourceSafe command line interface:

         SS Locate myfile.txt
   

   will find all occurrences of myfile.txt that have not been deleted, and those that have been deleted but not removed permanently. If multiple copies of myfile.txt are found, use the SourceSafe Physical command to identify which project contains which instance of myfile.txt.

2. A recursive History of the top level project will tell what files have been added, deleted, destroyed, purged, or branched.

3. If a file has been shared, viewing the Links for that file will show which projects share the file.

4. If a file has been branched, viewing the Paths for that file will show which projects contain branches of the file.

The log file, qusaaaaa, can be deleted only if all instances of myfile.txt that have a link or path to the copy that is causing the error have been removed permanently from the database.

If this is not the case, locate a copy of myfile.txt that is identical to the last checked-in version. If no suitable copy exists, restore the file pair from a backup. Deleting and adding myfile.txt back should only be used in a "worst case" situation in which neither of the previous two methods is possible.

REFERENCES

For additional information, please see the following articles in the Microsoft Knowledge Base: