How SourceSafe Uses the DATA Directory

Last reviewed: December 11, 1996
Article ID: Q157984
The information in this article applies to:
  • Microsoft Visual SourceSafe, 32-bit, for Windows, versions 4.0, 4.0a, 5.0

SUMMARY

The Visual SourceSafe DATA directory is not complex, but some explanation of its structure may be needed. This article describes the file/directory structure of the DATA directory and provides an overview of each directory's use.

MORE INFORMATION

SourceSafe will create 26 subdirectories in the DATA directory named "A" through "Z." In addition, you may have up to three additional directories named BACKUP, LOCKS, and LOGGEDIN (version 5.0 only). SourceSafe will never create more than 29 sub-directories in the data directory (28 in version 4.x).

Each file or project added to SourceSafe will have two files associated with it in the database (called a file pair). By design, the root project ($/) is stored in the file pair AAAAAAAA and AAAAAAA.A. The first file or project added to an empty database will be stored in the "B" directory and will be named BAAAAAAA and BAAAAAAA.A. The file with an extension (the data file) is a byte-for-byte copy of the most recently checked-in version of the file or project. The other (known as the log file) contains the history of the file as well as other information such as the name of its parent project, etc.

Each time you modify a file in SourceSafe (through a Check-in, Label, Branch, Merge, etc.), SourceSafe adds these changes to the log file and then rewrites the data file to keep it current. On an Intel Machine, each time the data file is rewritten, its extension will change from .A to .B, or vice versa. For example, if MYFILE.TXT is being stored in the file pair BAAAAAAA and BAAAAAAA.A, checking out MYFILE.TXT, modifying it and checking it back in again will result in BAAAAAAA and BAAAAAAA.B (BAAAAAAA.A will be deleted). Repeating the above procedure will again result in BAAAAAAA and BAAAAAAA.A. If you are using a Macintosh client, there may be an additional file with an extension of .C or .D. If you are using a UNIX box, you may have an additional file with an extension of .E or .F. If you have a .C or .E file, you should also have a .A file. If you have a .D or .F file, you should also have a .B file.

SourceSafe sequentially distributes files to the directories labeled "A" through "Z" as files are added to the database. For example, if the file pair for "FILE1" is placed in "B," the file pair for FILE2 will be placed in "C," the file pair for FILE3 will be placed "D," and so on. The file pair for the 27th file added will go back to "A" because it is the next directory after "Z." Its name will be ABAAAAAA.A. As files are added to the "A" directory, they will be named ACAAAAAA.A, ADAAAAAA.A, AEAAAAAA.A, and so on. The first letter of these file names will be the same as the directory in which they reside.

The BACKUP directory is created by ANALYZE.EXE when it is executed against the database. If ANALYZE is run with the -f switch, this directory will contain a backup copy of each file that was modified by ANALYZE. Anytime ANALYZE is executed, a log file (ANALYZE.LOG) that contains information on potential problems encountered by ANALYZE will be placed in this directory.

The LOGGEDIN directory is used by SourceSafe (version 5.0 only) to keep track temporarily of who is logged into the database.

The LOCKS directory may be used to keep track of temporarily-locked files. This feature is enabled when the LOCK_MODE = LOCKFILES setting is placed in the server's SRCSAFE.INI.


KBCategory: kbusage kb3rdparty kbhowto
KBSubcategory: ssother
Additional reference words: 4.00 4.00a 5.00 kbdss



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: December 11, 1996
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.