File data is stored in clusters, and the Windows operating system uses a file table to determine where a file begins and on which clusters it is stored. With FAT, the file table used is called the root directory table. It defines the starting cluster of each file in the file system. This cluster has a pointer to the second cluster, and the second cluster has a pointer to the next, and so on until you get to the final cluster used by the file, which has an EOF marker. With NTFS, an MFT is used. If a file's data can't fit within a single record in this table, clusters belonging to the file are referenced using VCNs that map to starting LCNs on the disk. If a file's pointer or mapping is lost, you might not be able to access the file. Errors can also occur for pointers or mappings that relate to the file tables themselves and to the pointers or mappings for folders.

FAT tries to prevent disk integrity problems by maintaining a duplicate file allocation table that can be used to recover the primary file allocation table if it becomes corrupted. Beyond this, however, FAT doesn't do much else to ensure disk integrity. NTFS, on the other hand, has several mechanisms for preventing and correcting disk integrity problems automatically. NTFS stores a partial duplicate of the MFT, which can be used for failure recovery. NTFS also stores a persistent history of all changes made to files on the volume in a log file, and the log file can be used to recover NTFS metadata files, regular data files, and folders. What these file structure recovery mechanisms all have in common is that they are automatic and you as an administrator don't need to do anything to ensure these disk housekeeping tasks are performed. These mechanisms aren't perfect, however, and errors can occur.

The most common errors relate to the following areas:

Using Check Disk, you can check for and correct any of the common disk errors discussed previously. Check Disk works on FAT, FAT32, and NTFS volumes and primarily looks for inconsistencies in the file system and its related metadata. It locates errors by comparing the volume bitmap to the disk sectors assigned to files. For files, Check Disk looks at structural integrity, but won't check for or attempt to repair corrupted data within files that appear to be structurally intact.

Check Disk has two modes in which it can be run. It can analyze a disk, checking for errors, but not repairing them. Or it can analyze a disk and attempt to repair any errors found. New for Windows Server 2003 is that Check Disk has been optimized so that it runs faster than previous versions.

You can run the graphical version of Check Disk by using either Windows Explorer or Disk Management. Right-click the volume, and choose Properties. In the Tools tab of the Properties dialog box, click Check Now to display the Check Disk dialog box, as shown in Figure 20-15. If you want to analyze the disk but not repair errors, click Start without selecting either of the available options. If you want to check for errors and repair them, select Automatically Fix File System Errors, and click Start. You can also check for and repair bad sectors by selecting Scan For And Attempt Recovery Of Bad Sectors.

Figure 20-15. Check the disk for errors and repair them or perform analysis only

To fix errors, Check Disk needs exclusive access to the volume. If Check Disk can't get exclusive access to files (because they have open file handles), Check Disk will prompt you, as shown in Figure 20-16. If you click Yes, Check Disk will analyze and repair the disk the next time the system is started.

Figure 20-16. Check Disk needs exclusive access to some Windows files to fix errors

Inside Out: Marking disks for checking on startup

Check Disk can't get exclusive access to a volume if it has open file handles. As a result, you must either use the command-line version and dismount the volume or schedule Check Disk to run the next time the system is started. When you schedule Check Disk to run, the operating system marks the disk as dirty, which means it needs to be checked and repaired. You can mark a disk as dirty using the FSUTIL DIRTY command. Type fsutil dirty set followed by the drive designator, such as fsutil dirty set c:. If you want to determine if Check Disk is set to run the next time the system is started, you can use the FSUTIL DIRTY command to do this as well. Type fsutil dirty query followed by the drive designator, such as fsutil dirty query c:.

Check Disk can also be run at the command line using ChkDsk (Chkdsk.exe). The key advantage of using the command-line version is that you get a detailed report of the analysis and repair operations as detailed in the sections of this chapter entitled "Analyzing FAT Volumes by Using ChkDsk" and "Analyzing NTFS Volumes by Using ChkDsk."

You can run ChkDsk in analysis mode at the command line by typing chkdsk followed by the drive designator. For example, if you want to analyze the C drive, you'd type chkdsk c:. To have ChkDsk analyze and repair volumes, you add the /F parameter, such as chkdsk c: /f. If you want to check for bad sectors and try to repair them as well, use the /R parameter (which implies /F as well, meaning ChkDsk will perform a full analysis and repair and then check and repair bad sectors).

The complete syntax for ChkDsk is as follows:

chkdsk [volume[[path]filename]] [/f] [/v] [/r] [/x] [/i] [/c] [/l:size]

Table 20-6 summarizes the options and parameters available and their uses.

When you run ChkDsk, you can get an analysis report. For FAT volumes, a disk analysis report looks like this:

The type of the file system is FAT.
Volume DATA3 created 2/19/2004 5:58 PM
Volume Serial Number is 7D11-2345
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.

    209,489,920 bytes total disk space.
         24,576 bytes in 6 hidden files.
         12,288 bytes in 3 folders.
    200,679,936 bytes in 279 files.
      8,773,120 bytes available on disk.

          4,096 bytes in each allocation unit.
         51,145 total allocation units on disk.
          1,970 allocation units available on disk.

Here, ChkDsk examines each record in the file allocation table for consistency. It lists all the file and folder records in use and determines the starting cluster for each using the root directory table. It checks each file and notes any discrepancies in the output. Any clusters that were marked as in use by files or folders but that weren't actually in use are noted and during repair the clusters can be marked as available. Other discrepancies noted in the output can be fixed during repair as well.

Disk analysis for NTFS volumes is performed in three stages, and ChkDsk reports its progress during each stage as shown in this sample report:

The type of the file system is NTFS.
Volume label is Data.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
Correcting errors in the master file table's (MFT) BITMAP attribute.
Correcting errors in the Volume Bitmap.
Windows found problems with the file system.
Run CHKDSK with the /F (fix) option to correct these.

    30009388 KB total disk space.
    25116620 KB in 44945 files.
       14456 KB in 2557 indexes.
           0 KB in bad sectors.
      114972 KB in use by the system.
       65536 KB occupied by the log file.
     4763340 KB available on disk.

     4096 bytes in each allocation unit.
        7502347 total allocation units on disk.
        1190835 allocation units available on disk.

During the first stage of analysis, ChkDsk verifies file structures. This means ChkDsk examines each file's record in the MFT for consistency. It lists all the file records in use and determines which clusters the file records are stored in and then compares this with the volume's cluster bitmap stored in the $Bitmap metadata file. Any discrepancies are noted in the ChkDsk output. For example, any clusters that were marked as in use by files but that weren't actually in use are noted, and during repair the clusters can be marked as available.

During the second stage of analysis, ChkDsk verifies directory structure by examining directory indexes, starting with the volume's root directory index, which is stored in the $Metadata file. ChkDsk examines index records, making sure that each index record corresponds to an actual directory on the disk and that each file that is supposed to be in a directory is in the directory. It also checks to see whether there are files that have an MFT record but that don't actually exist in any directory, and during repair these lost files can be recovered.

During the third stage of the analysis, ChkDsk verifies the consistency of security descriptors for each file and directory object on the volume using the $Secure metadata file. It does this by validating that the security descriptors work. It doesn't actually check to see if the users or groups assigned in the security descriptors exist.

If problems are found, ChkDsk will repair them only if you've used the /F parameter. Alternately, you can use the /X or /R parameter as well, and each implies the /F parameter. If you use the /R parameter, ChkDsk will perform an additional step in the analysis and repair that involves checking each sector on the disk to make sure it can be read from and written to correctly. If it finds a bad sector, ChkDsk will mark it so data won't be written to that sector. If the sector was part of a cluster that was being used, ChkDsk will move the good data in that cluster to a new cluster. The data in the bad sector can be recovered only if there's redundant data from which to copy it. The bad sector won't be used again, so at least it won't cause problems in the future. Checking each sector on a disk is a time-intensive process—and one that you won't perform often. More typically, you'll use ChkDsk /F to check for and repair common errors.