Microsoft Corporation
March 1999
Summary: Outlines recommended practices to help prevent data corruption in Microsoft® Visual SourceSafe™. (12 printed pages) Includes a discussion on the data repair Analyze tool that ships with the product. Covers:
Introduction
General Database Recommendations
How Visual SourceSafe Tracks Files
Finding and Repairing Data Corruption
Backup and Restore
Article Reference
These topics are not intended to be the sole reference for Visual SourceSafe. Product documentation, the Help files, and the Microsoft Knowledge Base are also good resources. The Knowledge Base is the most up-to-date source of breaking news and information on Microsoft products.
Under normal operation in a stable environment, Visual SourceSafe provides excellent storage and security for your current source data and past revisions. As with any database product, however, under typically imperfect conditions it is possible for data corruption to occur. This article outlines recommended practices to help avoid corruption problems. Although all the practices will help minimize the impact of corruption, one of the most valuable is using a data repair utility called Analyze. The Analyze tool ships with the Visual SourceSafe product. It checks for and repairs many common data write errors. Run Analyze on your Visual SourceSafe database in concert with your regular tape backup schedule to ensure the stability and security of your source data.
Under normal usage, your Visual SourceSafe database should not exceed 3-5 GB in size. In determining an appropriate size, consider the amount of free space on the server, the relationship among the projects being stored, the amount of file history you need quickly accessible, and user tolerance for reduced performance. Although Visual SourceSafe does not have any built-in size limitation, on very large databases it takes longer to perform normal operations and maintenance tasks, such as running Analyze. Visual SourceSafe does not limit the number of databases that can be put on a file server.
To reduce potential file size, keep projects that are not interrelated in separate databases. You can use the Archive and Restore utilities, included in Visual SourceSafe version 5.0 and later, to move projects to another database or to remove outdated history from a project.
Although you can store Visual SourceSafe databases on any Microsoft Windows®-compatible file server (Windows NT, Novell, Banyan, and so on), database performance is best on Windows NT. Not only are network operations generally faster, but the server-based Windows environment allows you to run Analyze and other highly intensive file I/O operations directly on the server, often dramatically decreasing execution time.
Run the Analyze tool shipped with Visual SourceSafe to detect and repair problems in the database structure. Running Analyze regularly, especially in high-use situations, allows you to discover small problems and fix them before they become worse. Run Analyze weekly or, at minimum, monthly as part of regular maintenance.
Tip While running Analyze directly on your production database, you must lock out users. To minimize the impact on users, restore your regular backup to another location and run Analyze on that copy. If you detect problems in the backup 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. This method also checks the validity of the backup strategy.
Create a physical list of all items in the database each time you run the Analyze utility. The physical list is useful in determining what logical file name is related to an error, based on the physical file name (for example, Abcaaaaa.a) for which the error is reported.
For more detailed information on Analyze see the section "Finding and Repairing Data Corruption" later in this document.
Caution Do not allow Visual SourceSafe or the Analyze tool to run out of disk space while running.
Running out of disk space in the middle of a complex operation can create serious database corruption. Visual SourceSafe does check for disk space, but due to performance concerns it does not check for space on every disk write operation. To avoid possible database corruption, make certain there is enough free space on the server that a complete copy of the database could be created during normal Analyze operations.
Use the Sharing and Branching features of Visual SourceSafe with discretion. Avoid Sharing or Branching across top-level projects because it complicates the process of archiving the project and restoring it into another database. Also note that when you branch files and then delete them, the space is not recovered until all copies of the branched file are destroyed in the database.
The acceptable number of users varies, depending on the performance of the server and the network. Again, controlling the size of the database will improve performance and allow more users to access the database with reasonable performance. The number of full-access users you have determines the number of licenses that you need for Visual SourceSafe.
All users must have create, modify, change/edit, and delete privileges for files in the Data folder and its subfolders in the directory tree.
Each database has its own User and Rights management systems. You cannot interrelate these files.
Users' Ss.ini files are limited in size to 64 KB and a maximum of 10 different machine-specific settings. Each time a user logs on from a different machine the Ss.ini saves the window positions and other machine-specific information. If you are experiencing unusual, user-specific problems try deleting unnecessary entries in the user's Ss.ini file.
To maintain file integrity, make certain that all users have their own working folders for all projects. When multiple users share a working folder, a file checked out by one user may be modified by anyone with access to that folder. Maintaining separate working folders ensures that users only modify files they have checked out themselves.
Synchronize the dates and system clocks for all Visual SourceSafe client machines with the Visual SourceSafe server. This prevents check-in and check-out operations from appearing to happen out of sequence and affects any labels that are applied. Synchronizing dates and system clocks is particularly important when users from different time zones access the same database.
You can set up a Windows NT Server to act as a Domain Time Source server for users to synchronize their local date and time with the network. For additional information, see the Knowledge Base article "How to Set Up and Synchronize with Domain Time Source Servers (search on article ID Q131715).
Avoid creating a new database by copying an existing one. This method can potentially cause problems because the globally unique indentifier (GUID) in the Um.dat will be the same for both databases. For details on how to create a new database, see Knowledge Base article Q123467, "How to Create a New Database in SourceSafe."
To move a Visual SourceSafe installation, copy the entire VSS folder and all of its subfolders to the new location. However, do not use XCOPY to do this, due to the fact that it does not copy some zero-byte files. Use Windows Explorer to copy the folder(s). After you have copied the installation, the Visual SourceSafe clients need to change the #include statement in their local Srcsafe.ini to reflect the new location. No other modifications are necessary. To move just the database itself, perform the same operation on the Data folder and then modify the DATA_PATH line of the server Srcsafe.ini instead of the client Srcsafe.ini. When specifying the DATA_PATH, use the UNC method (i.e., \\SERVER\SHARE). For additional details, see Knowledge Base article Q176909, "HOWTO: Move a VSS Database or Project to New Location."
When using Visual SourceSafe through the integration in the development environments (Microsoft Visual Basic®, Microsoft Visual C++®, Microsoft Access, Microsoft FrontPage®, and so on) use the integrated component to perform Visual SourceSafe operations that can be done within that environment. For example, do not check out and check in files from both the Visual SourceSafe Explorer and integrated environments.
Visual SourceSafe is a file-based version control system that is designed for use on multiple, industry-standard network servers. No special program needs to be executed on the server during normal usage. The core of a Visual SourceSafe database is the Data directory; it has a unique structure that is designed to allow maximum flexibility. A Visual SourceSafe Database consists of the following files and folders.
File/folder | Description |
SrcSafe.ini | Visual SourceSafe database global settings and configuration information for all users. |
Users.txt | List of all users of the Visual SourceSafe database. |
Data\Aaaaaaaa.cnt | Physical name of last file added to the database. |
Data\Crcs.dat | CRC information used to speed up the get and check-out processes (Visual SourceSafe 6.0 format databases only). |
Data\Names.dat | Long file name information. |
Data\Rights.dat | User and project security information. |
Data\Status.dat | Visual SourceSafe Explorer cache file (used to speed up the display of the Visual SourceSafe Explorer). |
Data\Um.dat | User management information (names and passwords) and the database identifier (GUID). |
Data\Version.dat | Visual SourceSafe database version. |
Data\A…Z (folders) | Folders containing log files and data files. |
Data\Backup (folder) | Contains analyze log file (analyze.log), list of bad files (analyze.bad), and backups of files changed by analyze. |
Data\Labels (folder) | Label cache information used for label promotion (Visual SourceSafe 6.0 format databases only). |
Data\Locks (folder) | Used if Visual SourceSafe locking is enabled. |
Data\Loggedin (folder) | Contains user login files and an Admin.lck file, if the database is locked. |
Users (folder) | Contains Template.ini, which stores default values for the Ss.ini file for new users. The Users folder also contains a subfolder for each user. This subfolder contains an Ss.ini file defining user-specific settings. The Admin folder also contains Ssadmin.ini, which defines administrator settings. |
Visual SourceSafe creates two files in the Data directory for every file and project that you add to Visual SourceSafe (with one exception described later in this section). These file pairs are distributed evenly across the A through Z subdirectories in the Data directory. The file without an extension (such as Qrbaaaaa) is the log file for the file type being stored. The log file contains internal information for Visual SourceSafe, such as who added the file, where it exists, and all the differences between the versions of the file. The file with an .a or .b extension (such as Qrbaaaaa.a) is the most recent version of the actual file, stored under a Visual SourceSafe physical name. Each time a file is checked in, the extension it is saved with alternates between .a and .b. When a user checks in a file, it is copied from their working directory to the Data directory and renamed to the physical name with either an .a or .b extension, whichever is not currently there. Visual SourceSafe then calculates the differences between the .a and .b files and stores it in the log file (the file without an extension). Once the log file is updated, the old copy of the data file is deleted. Under normal circumstances you should never have both .a and .b extensions for one physical file name.
When you share a file from another, no new file pair is created in the Visual SourceSafe database. Instead, Visual SourceSafe creates a reference in the original file's log, noting that the file also exists in another project.
Use the Analyze tool, located in the Microsoft Win32® directory, to check for and correct corruption problems. You should run it as frequently as is practical—once a week is recommended, or at a minimum, once a month. Analyze checks all the files in the Visual SourceSafe Data directory for corruption or disconnected links and often repairs these with proper switch settings. Because Analyze is so thorough it can be slow to run.
For best performance, all users should log off Visual SourceSafe before you run Analyze.exe. If you choose to use the -F switch to repair problems, users are required to log off. However, if you want to run Analyze.exe without requiring users to log off, you need to use the -X switch.
Note Due to the amount of file I/O required, you can dramatically improve performance by running Analyze local to the data (that is, on a Windows NT Server) rather than across the network.
Analyze has several switches you can use to tell it what to do when running. Do not try to use every switch at once. The more Analyze is required to do, the longer it takes to run.
When Analyze is run it executes in the following four passes.
Pass 1 | Analyze checks every file in the Data directory to make sure that it is valid and is not corrupt. |
Pass 2 | Analyze checks the relationships between parents (projects) and children (files and projects). |
Pass 3 | Analyze checks the relationships between shared and branched files. |
Pass 4 | Analyze checks the files Um.dat, Rights.dat, and Names.dat and performs cleanup operations. |
Analyze supports the following switches.
Switch | Description |
-B<folder> | Specify the folder to use for backup. |
-C | Compress unused space. (This simply removes blank space and does not compress the log files.) |
-D | Delete unused files. |
-DB | Delete the Backup folder.
Caution If you find corruption, create backup copies of logs before running Analyze with the -DB switch. |
-F | Automatically fix files with corruption. (Requires users to log off of database.) |
-I- | When the analysis is complete the program exits. (Useful if running in a batch script.) |
-V1 | Show only critical errors. (This is the default setting, if no -V switch is used.) |
-V2 | Show only significant errors. |
-V3 | Show all errors and inconsistencies. |
-V4 | Show errors, inconsistencies, and informational notes. |
-X | Do not attempt to lock the database when analyzing. (Recommended only when users must remain logged on while Analyze.exe runs; -X cannot be used with -F.) |
Running Analyze in the following pattern provides good coverage.
Command line | Description |
Analyze -V2 <Database Path> | The first pass should always be a nonfixing pass to locate any problems before trying to fix them. |
Analyze -F -V2 <Database Path> | If errors are reported in the first pass, run again in fix mode to correct them. |
Analyze -F -C -V2 <Database Path> | Errors corrected by Analyze in the first fix mode pass can unmask other problems that could not be seen before. Run a second fixing pass and use the -C option this time, to remove any unused space in the log files. |
Each time Analyze runs it places an Analyze.log file in the Backup folder along with a file called Analyze.bad. The Analyze.bad file contains a list of all files in which Analyze found problems. When Analyze fixes a file it first creates a copy of the file in the Backup folder, so that the repair can be undone if necessary. Each time Analyze runs it requires that the Backup folder be empty or not exist. If there is sufficient disk space, it is a good practice to rename the Backup folders, instead of deleting them. This history can prove very useful in troubleshooting corruption issues. The errors and messages reported by analyze are discussed at length in Knowledge Base article Q152807, "INFO: Error Messages from Analyze Tool of Visual SourceSafe."
Analyze can also re-create the Status.dat, Names.dat, and Rights.dat files. To do this, simply rename or delete the files you want rebuilt and run Analyze -F. Analyze re-creates the Names.dat file with the spaces in long file names appearing as underscores. You then need to rename the file using the Visual SourceSafe Explorer. The Rights.dat file is re-created, but as an empty structure; you need to readd the rights for each user.
Microsoft occasionally updates the Analyze tool to include more checking or to improve performance. For the latest version of Analyze please visit the Microsoft Visual SourceSafe Web site, located at http://msdn.microsoft.com/ssafe/default.asp.
When backing up your Visual SourceSafe database, be certain you are getting a full backup of the database. Although you can use incremental backups, avoid them due to the possibility that some of the files from the database may not be able to be restored. If users are logged on to Visual SourceSafe and actively using the product, the files they have open will not be backed up by most standard backup utilities. Several backup and copy utilities allow you to back up open files. You can use these utilities, however, if someone is actively updating a file in Visual SourceSafe when the file is backed up; it is possible that the backup will be corrupt.
Visual SourceSafe automatically closes any files opened by Visual SourceSafe or an integrated application after 15 minutes of inactivity. (This requires Service Pack 3 of Visual SourceSafe 5.0 or later.) The user still appears to be logged on to Visual SourceSafe and the files will be reopened when they start working again. The Rights.dat and Status.dat files remain open, however, anytime users are logged on, and will not be backed up. You can rebuild these if needed using the Analyze utility. Each time the administrator modifies the rights by project information for a Visual SourceSafe database, Visual SourceSafe copies the Rights.dat file to a Rights.bak file. If necessary, you can rename the Rights.bak file during a restore process.
Note Do not schedule Analyze to run at the same time as a backup of the database! If the backup program has files open that Analyze is trying to open, Analyze will shut down unexpectedly. Backups should be performed regularly, as part of the daily or weekly file maintenance and security process.
Caution Never restore a complete backup of a database over an existing database. Visual SourceSafe maintains very complex links between files. Restoring a whole database backup over an existing database may confuse the links between files and cause incorrect versions of the files to be displayed in the database.
Q153285 FAQ: Will VSS 5.0 be able to read a VSS 6.0 database?
Q153925 FAQ: How Can I Find Out if My VSS Database Has Been Upgraded?
Q123471 HOWTO: Change the Data Directory Location
Q123472 HOWTO: Create a Unique SRCSAFE.INI File
Q131447 HOWTO: Use PHYSICAL Command to Find SourceSafe Database File
Q131448 HOWTO: Rebuild Corrupt RIGHTS.DAT File
Q138296 HOWTO: Use UNC Paths in Visual SourceSafe
Q138344 HOWTO: Set up a Shadow Dir in Visual SourceSafe Administrator
Q138475 HOWTO: Set Up Multiple Check Outs on a Project Basis
Q140537 HOWTO: Change the Data Directory Location for Integration Apps
Q150648 HOWTO: Resolve Files Checked Out by an Unavailable User
Q153500 HOWTO: Recover Disk Space in Visual SourceSafe
Q153873 HOWTO: Upgrade from SourceSafe 3.x to Visual SourceSafe 4.0
Q163797 HOWTO: Lock a SourceSafe Database
Q167290 HOWTO: Enable Visual SourceSafe Locking
Q175950 HOWTO: Change the Name of a Visual SourceSafe Database
Q176350 HOWTO: Open Visual SourceSafe to a Specific Database
Q176909 HOWTO: Move a VSS Database or Project to New Location
Q191289 HOWTO: Enable Event Error Logging for FrontPage 98 & SourceSafe
Q194826 HOWTO: Designate a Visual SourceSafe project as a Web Project
Q124525 INFO: How SourceSafe Locks Files in the DATA Directory
Q131022 INFO: Required Network Rights for the SourceSafe Directories
Q131450 INFO: Description of Files in the \SS\DATA Directory
Q133018 INFO: Visual SourceSafe Setup Registration Settings
Q135643 INFO: Basic Troubleshooting Converting from Delta to SourceSafe
Q138298 INFO: Visual SourceSafe System Capacities and Specifications
Q138343 INFO: New Features of Ddconv.exe in Visual SourceSafe
Q138479 INFO: Required Rights for SourceSafe Commands
Q139891 INFO: Visual SourceSafe Installation is Processor Specific
Q140316 INFO: All Variable Settings for Visual SourceSafe .INI File
Q148511 INFO: Default Content of the Srcsafe.ini File
Q149382 INFO: Setting Options You Can Modify in the Srcsafe.ini File
Q150645 INFO: Minor Inconsistencies in the Header Log for
Q152807 INFO: Error Messages from Analyze Tool of Visual SourceSafe
Q153872 INFO: DDConv Messages of Visual SourceSafe 4.0
Q156448 INFO: Some Files and Projects are Upper Case after Upgrade
Q157714 INFO: How SourceSafe Stores Log Files
Q157984 INFO: How SourceSafe Uses the DATA Directory
Q157985 INFO: Anyone Can Run SSARC.EXE if There Is No Admin Password
Q158702 INFO: How ANALYZE Passes Work
Q166259 INFO: Visual Interdev/Visual SourceSafe Integration Discussion
Q168634 INFO: When -d Switch of Analyze Deletes Files
Q170749 INFO: What Window Position Values in Some INI Variables Mean
Q171117 INFO: Increasing Page File Size May Help When Running Analyze
Q176553 INFO: Database Architecture Changes in 4.0, 4.0a, 5.0
Q176875 INFO: The Primary Functions of Ssarc.exe and Ssrestor.exe
Q186361 INFO: ERR "...Some links may not be restored"
Q193583 INFO: SSInt.exe Is Added to Visual SourceSafe 6.0
Q195024 INFO: Visual SourceSafe Creates a VSSVer.scc File
Q123476 PRB: SoureSafe "Error locking file" on Windows NT or Multi-User
Q129187 PRB: Files Truncated One Byte When Placed in SourceSafe
Q129188 PRB: PVCS Labels Are Not Converted with PVCS_SS.EXE
Q132421 PRB: Lock_Mode = lockfile Causes "Timeout Locking File" Error
Q133017 PRB: Branching Files in SourceSafe Causes Lost Disk Space
Q136401 PRB: Data Path Errors Starting SourceSafe
Q140593 PRB: Error "Names.dat may be corrupt" Appears
Q140594 PRB: Local SSADMIN Writes to Local (Not Server) Srcsafe.ini
Q142763 PRB: Path Problems on Client Installation of SourceSafe
Q145744 PRB: Client Installed from ReadOnly Server Won't Start
Q147837 PRB: "File not Found" Error Message During Check In
Q149378 PRB: File Not Found Error When You Add New Users
Q153501 PRB: "Error reading from file" When Logging into SourceSafe
Q153502 PRB: Unable to Open Project Error When Running Analyze
Q154486 PRB: Access Denied or File Locked When Log In to SourceSafe
Q154829 PRB: Rights by Project Are Not Always Inherited
Q155584 PRB: Files Missing or Not Displayed in GUI Interface
Q155631 PRB: Message "Error Writing to File" When Checking In File
Q155754 PRB: File Could Not Be Mapped to the SourceSafe Project
Q155888 PRB: Binary Files with Keyword Expansion Corrupted
Q156717 PRB: Rollback of Shared File Forces a Branch
Q157533 PRB: PVCS to SourceSafe Conversion Fails
Q159278 PRB: Can Log on to a Locked Visual SourceSafe Database
Q159283 PRB: ANALYZE Error "Unable To Create the Filemapping…"
Q160914 PRB: The Data File for () Was Not Found
Q161610 PRB: SSARC/SSRESTOR Change 4.0 Database to 4.0a/5.0 Format
Q162530 PRB: Invalid Handle on Client When Journal_Text Set to Bad Path
Q162531 PRB: Filenames Starting with Tilde Not Shown in Analyze -PSS
Q164263 PRB: "Incompatible Database Version" - ANALYZE vs. Explorer
Q167258 PRB: Analyze Leaves Files with .old Extension in Database
Q167263 PRB: <filename> is Already Open
Q172157 PRB: Do Not Use SourceSafe When Running SSARC or SSRESTO
Q172158 PRB: Setup Error: "You must have NT administrative privileges"
Q172376 PRB: Ddcerr.log Reports "DDCONV initializing" During Upgrade
Q173387 PRB: Restoring an Archive of an Entire Database
Q176732 PRB: Read-Only Files in Shadow Folder Are Not Updated
Q176878 PRB: Replacing Names.dat File Changes Long File Names
Q186402 PRB: User Admin Not Found
Q186420 PRB: Status.dat File Is too Large
Q186469 PRB: Rights from Parent Project not Inherited
Q189110 PRB: "File Already Open" Error w/VSS DB on Unix Server
Q193586 PRB: Error "Rights.Dat is already open" When Running Ddupd.exe
Q190881 SAMPLE: Analyze6.exe Utility for Visual SourceSafe
Q154008 FAQ: What Microsoft Products Does VSS Integrate with?
Q123473 HOWTO: Increase Performance in SourceSafe
Q123474 HOWTO: Logon With a Name Other than the System Logon
Q127104 HOWTO: Set Up Multiple SourceSafe Databases
Q133377 HOWTO: Search for SourceSafe Articles Using KBKeywords
Q138147 HOWTO: Use the SourceSafe Explorer to Modify the Ss.ini File
Q153493 HOWTO: Perform a RollBack Without Losing History
Q158219 HOWTO: Use SourceSafe Over a RAS or ISDN Connection
Q167134 HOWTO: Open Visual SourceSafe to a Specific Project
Q180945 HOWTO: Disconnect a Project from Source Control
Q123470 INFO: How SourceSafe Selects a Viewer for a File
Q124530 INFO: Visual SourceSafe Project Oriented Version Control
Q130176 INFO: Project versus File Labeling in SourceSafe
Q131772 INFO: Setting Compare to Checksum Speeds GET Command
Q131773 INFO: Setting Compare to Time Increases Speed of GET Command
Q132892 INFO: SourceSafe Might Modify Some Files
Q136325 INFO: Three Types of Drag-and-Drop with Visual SourceSafe
Q138299 INFO: Legal Visual SourceSafe Naming Conventions
Q138385 INFO: Visual SourceSafe Shortcut Keys
Q147585 INFO: The Mssccprj.scc File and How Is It Used
Q148512 INFO: Description of the Properties/About Command Line Commands
Q150644 INFO: Quotes Required in Command Line for Names with Spaces
Q157527 INFO: New Visual SourceSafe Commands and Functionality
Q157717 INFO: VSS 5.0 Readme: Sec. 2, General Notes and Tips "
Q157718 INFO: VSS 5.0 Readme: Sec. 3, New Features in Visual SourceSafe"
Q157719 INFO: VSS 5.0 Readme: Sec. 4 & 5, VSS 4.0/VSS Home Page Users "
Q157720 INFO: VSS 5.0 Readme: Sec. 1, Software Installation Information"
Q157982 INFO: Understanding Promotions
Q158218 INFO: Support Options for Visual SourceSafe
Q158469 INFO: Time Difference in Checking Out vs. Getting File in SourceSafe
Q164941 INFO: Command Line Equivalent of "Build Tree" Option
Q185696 INFO: "Invalid DOS path :" when Adding Files
Q186320 INFO: Determining if a Web Project is Source Code Controlled
Q131092 PRB: Keyword Expansion Is Case Sensitive
Q150643 PRB: Setting Wrong System Date Causes Lost Project History
Q155437 PRB: "Invalid DOS Path" Error Message
Q160888 PRB: VSS Explorer Error: "This Is an Integration Only Project"
Q162113 PRB: Project Modification Not Reflected in Shadow Directory
Q167262 PRB: Unable to Open User Login File
Q173065 PRB: Problems After Branching Integrated DevStudio Projects
Q184354 PRB: Working Folder for Subproject Not Inherited from Parent
Q184357 PRB: Visual C++ Opens Project in Wrong VSS Database
Q186236 PRB: SCC Project Opens Very Slowly with Norton Anti Virus
THE INFORMATION PROVIDED IN THIS DOCUMENT 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.