Media Share 9/MEDIASHARE_09.ISO/private/mpc93mar.zip/CHKDSK.DAT

Text File | 1993-02-15 | 18KB | 341 lines

                           Understanding CHKDSK

     By: Ellen Siever, Boston Computer Society

     Have you ever issued the CHKDSK command expecting to find out that
     everything is fine, only to discover instead that something is wrong?
     Before I switched to DOS 5.0, I used CHKDSK as an easy way to see how
     much free space was available on my hard drive, expecting to get the
     warm fuzzy feeling that all's well with the world. Or at least with
     the hard disk. Except that occasionally what I got instead was
     something like this:

            Errors found, F parameter not specified.
            Corrections will not be written to disk.

            16 lost clusters found in 2 chains.
            Convert lost chains to files (Y/N)?


     I'll discuss what this message means and what to do about it
     later--for now, it's sufficient to say that it means there is a
     problem that needs to be dealt with. Note that this was pre-DOS 5.0;
     these days the message refers to lost allocation units instead --an
     allocation unit is the DOS 5.0 term for what had been known as a
     cluster. I'll use both terms interchangeably in this article.

     So I learned to take care of lost cluster problems. Then one day
     CHKDSK came up with the following message:

            C:\PCT\PCSECURE.CFG is cross linked on allocation unit 1709
            C:\NAV\INSTALL.EXE is cross linked on allocation unit 1709

     Since I hadn't known that CHKDSK ever gave anything other than "all's
     well" or "lost cluster/allocation unit" messages, that was a surprise
     to me, and it led me on a search for more information about CHKDSK,
     which in turn resulted in this article.

                             Hard Disk Organization

     At the lowest level, your hard disk is organized into units known as
     sectors. Each sector can contain 512 bytes. Files are stored on the
     disk in groups of sectors that were called clusters prior to the
     release of DOS 5.0, when they became known as allocation units. The
     number of sectors per allocation unit is fixed and depends on the size
     of the disk.

     DOS maintains two structures for the purpose of locating files on the
     disk: the file allocation table (FAT) and the file directory. (There
     are actually two copies of the FAT, but DOS only uses one of them.)

     The FAT is used to keep track of the disk sectors. Every FAT entry
     represents one cluster and contains a code that indicates the status
     of the cluster. For a cluster that is in use by a file, the FAT entry
     either contains the number of the next cluster used by the file, or it
     contains an end-of-file marker if it is the last cluster. If the
     cluster is not in use, the entry indicates either that it is free and
     available for use, or that it is a bad cluster and cannot be used. DOS
     uses the next-cluster information in the FAT to chain its way through
     the sectors of a file when you issue a command that accesses the file.
     DOS needs to have this information because files are not necessarily
     written on contiguous clusters, and it has to be able to move from one
     cluster to the next.

     The directory contains the starting cluster number for each file, in
     addition to the name, attributes, size, and creation date and time for
     the file. When you issue the DIR command, you are accessing the
     information in the file directory. DOS uses the starting cluster
     number from the directory to locate the entry in the FAT that will
     tell it where on the drive the file begins. It can then follow the
     chain of cluster numbers through the FAT.

                                 The Command

     The CHKDSK command verifies the logical structure of the disk not the
     physical structure, and it reports back to you. In checking that the
     interrelationships among the directory, the FAT and the disk itself
     are undamaged, it deals with the logical disk partitions. That is, if
     your hard drive is petitioned into multiple disks (C: and D:, for
     example), you have two disks as far as CHKDSK is concerned.

     In addition to checking the disk if you specify the /F switch, CHKDSK
     can also attempt to repair any damage that it finds. However, as you
     will see in more detail later, CHKDSK repairs can be of the brute
     force variety, and you should get in the habit of always issuing the
     command first without /F to identify any problems and then re-issuing
     it with /F if and when you are sure that is the best way to proceed.
     In some cases, it may be better to use other techniques or another
     program, such as the Norton Utilities or pc Tools, to correct disk
     problems found by CHKDSK.

     In general, for any problem other than lost clusters, try to use one
     of the major disk repair programs before running CHKDSK/F. Chances are
     good that will fix the problem.

     The syntax of CHKDSK is:

            chkdsk [d:] [filespec] [/f] [/v]

     The D: indicates the drive to be checked; the default is the current
     drive. In the normal case where there are no problems for CHKDSK to
     report, after you issue the command CHKDSK C:, you will see something
     like this:

            Volume MY_DISK created 05-28-1990 4:07p

                   81264640    bytes total disk space
                      98304    bytes in 4 hidden files
                     327680    bytes in 40 directories
                   34086912    bytes in 1053 user files
                   46751744    bytes available on disk

                       8192    bytes in each allocation unit
                       9920    total allocation units on disk
                       5707    available allocation units on disk

                     655360    total bytes memory
                     512944    bytes free

     This shows you how the space on your disk is allocated, how much is
     used, and how much is available. It also indicates the amount of
     memory available for running programs. If you include a filespec in
     the command, CHKDSK tells you whether the file is stored on contiguous
     blocks, and if not, how many it uses. For example, if you entered

            chkdsk c:\wp51\letters\*.*

     you might see the output shown above, followed by:

            C:\wp51\letters\xyzcorp.let Contains 2 non-contiguous blocks
            C:\wp51\letters\dbprog.let Contains 2 non-contiguous blocks

     This gives you information on how fragmented your disk is. You don't
     want your files to become too fragmented, because accessing files that
     are scattered across a disk takes longer and slows down overall system
     performance. If you start to see files with many non-contiguous
     blocks, you should consider running a utility to unfragment the disk.

     The /F switch is used with CHKDSK to repair disk errors. Every time
     you issue the CHKDSK command, CHKDSK goes through the motions of
     fixing the disk. But it won't actually make any changes unless you
     have specified /F in the command. The steps it takes to correct a
     problem depend on what it finds and are described in the following
     sections. Once CHKDSK has "fixed" the problem, you may still have work
     to do to finish restoring your files.

     The /v switch causes CHKDSK to display the name of every file in every
     subdirectory (and its complete path) as it checks the disk. If you are
     running a version of DOS earlier than 5.0, this can be a convenient
     way to get a full listing of all files on your disk. With the "new,
     improved" DIR command in DOS 5.0, /v seems to have lost much of its
     usefulness.

     Lost Clusters

     Lost clusters are the most common problem detected by CHKDSK. A lost
     cluster is one which is marked in the FAT as being in use, but which
     is not part of any file in the directory. A contiguous group of lost
     clusters is a lost chain. CHKDSK/F will convert each lost chain to a
     file if you answer Y, or will free the disk space if you answer N, to
     the "convert to file?" message.

     If you run CHKDSK (without /F), and you get a lost clusters message
     like the one shown in the example at the beginning of this article,
     CHKDSK has followed all the chains from the directory through the FAT
     and in doing so, it has noted that some number of entries in the table
     (16 in the example) are not part of any chain from the directory; in
     this case there are 2 chains involved.

     You can now re-run CHKDSK with /F, and it will ask you:

            16 lost clusters found in 2 chains.
            Convert lost chains to files (Y/N)?

     When you ran initially without /F, it didn't matter whether you
     answered Y or N to the prompt--CHKDSK wouldn't make any changes either
     way. But now that you've specified /F, if you answer Y, CHKDSK creates
     two files in your root directory, one for each chain, called
     FILE0000.CHK and FILE0001.CHK. It always adds one file per chain and
     numbers them sequentially starting with 0000.

     You can then examine each .CHK file with the TYPE command, with a
     utility program like Vern Buerg's List program, or with the text
     editor of your choice, to see if it contains any useful information.
     If so, you can rename the file to save it, or copy the data to another
     file. Otherwise, you can safely delete the .CHK files.

     Why do lost cluster problems occur? Usually it is because a program
     has ended before all files were properly closed. Maybe a program hung
     and you had to reboot or maybe there was a power failure. When I first
     used Ventura Publisher, I had problems getting it to work with my
     printer and used to use [Ctrl]+ [Alt]+[Delete] to reboot the system so
     I could try again. Not too surprisingly, I got a lot of lost clusters
     when rebooting killed Ventura with my text file open. I always allowed
     CHKDSK to convert the lost chains to files, I always checked the
     files, I always ended up deleting them, and my original files were
     always fine. But I'll continue to check each time I get a lost
     cluster, to make sure. What if you answer N to the "convert lost
     chains to files?" message? In that case, CHKDSK marks the sectors in
     those chains as free in the FAT, and they become available for reuse.
     Whether you answer yes or no, CHKDSK /F corrects the problem so that
     your system is once more internally consistent.

     The difference lies in whether or not you want to try to recover data
     from the lost chains. It's possible that recovering those lost
     clusters will lead to further lost clusters being uncovered, and that
     you will have to run CHKDSK several times before you get a clean
     report. At that point, you know you have uncovered and repaired them
     all.

     If you never run CHKDSK (or another disk analysis program), the lost
     allocation units remain unavailable, and you will essentially have
     lost the use of some of your disk space. If your system locks up
     during program execution and you have to reboot, or there is a power
     failure while you are in the middle of modifying a data or text file,
     it's a good idea to run CHKDSK when the system comes up next, to make
     sure everything is okay.

     Cross Linked Files

     Cross linked files occur when more than one chain is linked to the
     same entry in the FAT--that is, one cluster is assigned to more than
     one file. If that happens, you need to fix the problem before you can
     safely use either file. CHKDSK /F won't help, but it won't do any
     harm. The best solution (assuming that you have backups), and the only
     really safe one if the files are executables (as they were when it
     happened to me), is to delete both files and restore from the
     originals or from backups. I did that and everything was fine after
     that.

     If you don't have backups, try copying both files to a diskette or a
     new directory and erasing the original cross linked files. Then
     examine both files with an editor or file viewer--at least one and
     possibly both of them will have problems--and take whatever steps seem
     to be appropriate to fix them, depending on what you find.

     If you start to get cross linked files often, there may be a hardware
     problem that you should investigate.

     Size Allocation Errors

     If CHKDSK reports something like:

               Errors found, F parameter not specified
               Corrections will not be written to disk
               C:\DBPROG.LET
               Allocation error, size adjusted.

     that means that the size of the file as indicated in the directory
     does not agree with the number of entries in the FAT for the file. If
     you proceed to run CHKDSK /F, CHKDSK will assume that the FAT is
     correct and the directory is wrong, and it will force the file's
     directory entry to match the FAT entry. But this might not be the
     right solution, since it could be that the directory is correct and
     the FAT incorrect. In this case, it would be better to try one of the
     disk repair utilities first. Otherwise, run the DIR command to see if
     the file size it shows seems reasonable--if it does, try first copying
     the file somewhere else, then try deleting the original file and using
     an undelete utility to recover it.

     Invalid Allocation Unit

     If you get an "invalid allocation unit, file truncated" message,
     CHKDSK found a zero or an otherwise invalid "next cluster" pointer
     while following a chain through the FAT--one that doesn't point to
     another cluster and isn't an end-of-chain entry. As in the previous
     case, the best thing to do is run a utility disk repair program.

     If instead you run CHKDSK /F (run DIR first and see if the file length
     seems reasonable), it will "solve" the problem by writing an
     end-of-chain entry in place of the invalid entry (i.e., it will
     truncate the entry), or if the problem was with the first cluster (an
     invalid starting-cluster number), it will set the length to zero. You
     may then find the missing data in a .CHK file.

     Another alterative is to try deleting and then undeleting the file.

                     Invalid Subdirectory Entry

     This is another case where it the best solution is to try running a
     utility repair program first. The message

            C:\MYDIR
            Invalid sub-directory entry
            Convert directory to file (Y/N)?

     means that there is something wrong with the entry for the specified
     directory so that CHKDSK was unable to follow the directory tree.

     If you run CHKDSK /F, it turns the directory into a file. That may be
     the right solution if you know that the so-called directory is really
     a file and somehow the directory attribute mistakenly got set.

     If it really is a directory, first run a utility if you have one.
     Otherwise try to copy all the files in the directory and any of its
     subdirectories elsewhere, then delete the directory and subdirectories
     and recreate them from the files you moved.

     In the worst case, run CHKDSK /F, answer Y to the "convert to file?"
     prompt and try to recover as much as you can from the lost sectors
     that will be put into .CHK files.

     If CHKDSK discovers that the first byte of the FAT is not valid, it
     gives you the message "probable non-DOS disk." If it really is a DOS
     disk something has overwritten that initial byte. Once again, the
     utility programs can be used to correct the invalid byte.

                           CHKDSK and Windows

     What if you're running Windows? Does that affect your use of CHKDSK?
     Yes, it does. You should always exit from Windows before running
     CHKDSK with the /F switch. The Microsoft Windows User's Guide says to
     "always quit Windows before running the CHKDSK command with the /F
     option; never run CHKDSK /F from Windows. Loss of data might result."
     According to the DOS manual, this can happen if there are open files
     that haven't yet been recorded in the FAT--in that case, CHKDSK might
     report them as lost allocation units.

                               Conclusion

     Use CHKDSK first without /F; if you find a problem other than a lost
     cluster, try moving the affected file(s) and running one of the
     utility programs; as a last resort run CHKDSK /F and recover what you
     can from the files it creates. If the problem is a lost cluster, run
     CHKDSK /F, let it make the .CHK files, and examine them.

     If you don't already own one of the major utility packages, and if
     it's at all possible to do so, buy one--they have many useful features
     besides the disk fixing capabilities.

     Run CHKDSK periodically to make sure all is well. Even if all you ever
     see is lost cluster messages (and most likely that is what you'll see,
     if anything), it's worth doing, just to recover the disk space and
     make it available again for new files.

     And finally, make regular backups.

     **********************************************************************

     Ellen Siever is a freelance writer with over 20 years of technical
     computer industry experience.