Once you begin creating files, both you and the Operating system
need some way to keep track of them. How is this done? In DOS, the answer lies
with something called the File
Allocation Table (FAT). To understand how this important component
of DOS functions, let us first look at how disks are organized to store data.
Each disk is divided into sectors
which are 512 bytes in size. These sectors lie along tracks,
which are concentric rings on the disk. On a hard drive, these are created as
part of the low-level formatting process, and have been done at the factory.
In the old days users performed the low-level format themselves, but this has
not been necessary in some years. On an old floppy drive, you could conceivably
use sectors as the basic unit for storing file data, since the total number
of sectors would not be that large. On a 360K floppy disk, you would have 720
sectors to deal with. But on a large hard drive (like 100MB!!), you would need
to keep track of 200,000 of these sectors, with all of the overhead of of assigning
addresses to each sector and storing information about them in a table. Also,
512 bytes is pretty small as files go. Most files would require multiple sectors
to store their information, possibly hundreds of them. So the sectors were collected
into larger units, called clusters.
The cluster is sometimes referred to as the allocation unit, because
it is the minimum amount of space that can be allocated to a file.
For example, suppose the size of a cluster is 4096 bytes (i.e.
8 sectors). If you have a file that is 3000 bytes in size, it will be saved
using one cluster, and 1096 bytes of that cluster will be wasted. That is because
only one file can ever “own” a cluster. If your file was 5000 bytes,
you would use two clusters (total 8192 bytes), and 3192 bytes of the second
cluster would be wasted. Assuming that file sizes are a random number, you can
quickly show that on average you waste one-half of a cluster per file saved.
So there is some incentive to minimize this wastage, and the best way is reduce
the size of the partition. The reason for this has to do with how cluster sizes
are determined, and that leads us to the File Allocation Table.
The File Allocation Table (FAT) is a place on the disk where information
about the files is stored. Metaphorically, it is like the catalog in a library.
It is a table that stores the name of each file, and has a pointer to the place
on the disk where that file can be found. It also has a few other things. These
address pointer entries are stored as a binary number, and the number of bits
used determines the type of FAT in use. FAT-12, which is used for floppy disks
(and for hard disks smaller than 17MB, should you ever encounter one <g>),
stores the information in 12 bits per cluster. FAT-16, used in DOS and in versions
of Windows prior to the OSR-2 version of Windows 95, stores the information
in 16 bits. FAT-32, introduced to some computers in Windows 95 OSR-2, and in
general to most people in Windows 98, uses 32 bits to store this information.
Why does this matter? Because the maximum number of clusters is determined by
the bits available to address each one. Since each bit is a binary 0 or 1, the
formula is based on powers of two. Note that in FAT-12 and FAT-16, a few of
the theoretically available slots have been reserved for the use of the file
system. In FAT-32, 4 of the 32 bits in each address have been reserved for other
uses, leaving 28-bits for pure addressing.
|File System||Possible Entries||Actual Entries|
With this information, we can begin to do some calculations on
cluster sizes. On a hard drive formatted using FAT-16, here is what you would
find. (Note: these numbers are approximate, since hard drive sizes are stated
differently in some cases.) I will assume 5,000 files per hard drive as an example.
Note that cluster size has to be in even numbers of sectors (512 bytes each),
so if you are doing the calculations you will need to round up to the next even
multiple of 512.
|Hard Drive Size||Cluster Size||Estimated Wastage (5,000 Files)|
|100 MB||2048 (4 sectors||5 MB|
|500 MB||8192 (16 sectors)||20MB|
|800 MB||12,800 (25 sectors)||32MB|
|1.2 GB||18944 (37 sectors||47MB|
Since on a large hard drive the figure of 5,000 files is a drastic
underestimate (and note that you need to throw in all of the directories and
subdirectories, each of which uses a slot), you can see why FAT-16 is just not
acceptable for larger hard drives.
The Structure of FAT
Assuming you have a FAT-16 file system, you have 65,526 clusters
available for use when you begin. Of course, installing the operating system
is going to use up a lot of those slots, and each additional program you install
uses up many more. Here is how the FAT is structured:
|Reserved for DOS|
|Reserved for DOS|
|2 (used to store a small file)|
|4 (used to store data, extends to cluster 4)|
|5 (used to store data, extends to cluster 5)|
|7 (used to store data, extends to cluster 7)|
|0 (empty, available for use)|
|FFFh (used to store data, is the last cluster in the chain)|
|0 (empty, available for use)|
|Cluster 65524||0 (empty, available for use)|
|Cluster 65525||0 (empty, available for use)|
|Cluster 65526||0 (empty, available for use)|
As you can see, in each slot of the FAT there is status information.
If the cluster is free, the value of zero is recorded. If the cluster contains
data, but all of the data fits in that one cluster, the cluster number itself
is stored. If the data extends over multiple clusters, the number of the next
cluster in the chain is stored. If this is the last cluster in the chain, an
end-of-file marker is stored (the hexadecimal number FFF).
Ordinarily, you should not have any problems retrieving a file.
The FAT would have a pointer that says that your file MYFILE.TXT begins in cluster
10793, for instance, and would go there first and retrieve what is in that cluster.
In looking at the FAT entry, it would see the number 10794, for instance, and
know that the next cluster in that chain was 10794, and it would go there and
retrieve the contents of that cluster and append them to the end of the contents
of the first cluster. It would keep doing this until it reached the cluster
that had FFF stored, and it would know that this meant it had found the end
of the file and could stop.
Two things can go wrong with this, though. First, you can have
a situation where two different clusters, each part of a different file, point
to the same cluster as part of their chain. This is called cross-linked
files. The second problem is when you have clusters that appear to be
part of a chain, but the whole chain is not present. These are referred to as
lost clusters. When either problem is present, your file system
is unreliable and must be fixed. In early versions of DOS, you would fix this
using the external command CHKDSK.EXE, which is short for Check Disk. This program
would fix the file system by taking the clusters that were apparently part of
a chain (the lost clusters) and converting them to a file, usually something
like FILE0001.CHK. If you see this on your hard drive, you can usually delete
it safely since it is probably something that you cannot make sense of anyway.
But if you want you can try opening it in a text editor and see if it contains
anything you have been missing. If you have cross-linked files, CHKDSK.EXE will
convert them to two separate files that are no longer cross-linked. Of course,
at least one of them must be corrupt, since you cannot have two different files
use the one cluster. In later versions of DOS, and in Windows, CHKDSK.EXE was
replaced with a new utility called SCANDISK.EXE, which does essentially the
Because of these, and other problems that can occur, each DOS
FAT is actually duplicated as two consecutive duplicate copies. The first is
the normal working copy, and the second is a backup copy that is used if the
first becomes corrupted.
A related issue is file fragmentation.
When a file is deleted, the clusters it used are marked with a zero to indicate
that they are available for use. The contents are not removed,
though, which is why you can sometimes “undelete” a file if you act
before those clusters have been reallocated to a new file. Now, when a file
is saved, the operating system consults the FAT, and begins saving the file
in the first available cluster. If a second cluster is required, the next available
cluster is used. But this second cluster may be nowhere near the first. And
perhaps a third cluster is required, and it is nowhere near the other two. This
is file fragmentation. This can reduce performance since the heads of the hard
drive must travel some distance between each cluster to load the file. It is
a good idea to periodically defragment the drive, which means
to use a utility that moves the data contained in various clusters around so
that each file uses a series of contiguous clusters that are not spread out
all over the place. This means also updating all the records in the FAT so that
the file can be retrieved after the defragmentation has occurred. DOS has an
external command called DEFRAG that can be used to do this, and many utility
packages (such as Norton Utilities) had utilities for this purpose as well.
Directories and Directory Entries
In each FAT volume, right after the two copies of the FAT, we
come to the root
directory. In DOS, this is represented by the symbol \ (in Unix,
it is just the opposite: / ). This is the top of the directory structure, and
is always created when the disk is formatted and FAT is installed. The word
directory, in this context, actually has two different meanings.
Technically, a directory is a listing of contents. But in common usage, we often
use it to denote the container of the contents. For example, if you go into
a large office building, there is frequently a directory in the lobby that tells
you where you can find the particular office you are looking for. But that directory
does not “contain” the office, it simply tells you were to find it.
Yet in computers, we often use the word directory to mean the place where a
file is located, rather than the table where we look up its location. This can
get confusing. It is better to use the word directory to mean the table where
we look up the information, and use a different word, such as “folder”,
to mean where a folder is located. Of course, on a deep level these are all
metaphors we use to help us make sense of what the computer is doing. The computer
never gets confused, it is just us poor carbon-based life forms that get turned
If we use the word directory to mean the table where we look things
up, the root directory is a table that records the location of all of the folders
(directories) on the drive, and of any files that are not in one of those folders.
This table (on a hard drive) has 512 slots, and in each slot there is room for
a 32-byte entry. When a folder is created, that folder has a directory table
that also has 512 slots, each with a 32-byte entry. It follows that each folder,
from the root on down, can hold a maximum of 512 “objects”, where
those objects are either files or other folders. The 32-byte description allows
8 bytes for the file (or folder) name, 3 bytes for the file’s extension, and
additional bytes describe the attributes (read-only, system file, hidden, archive,
etc.), the date created or last modified, etc. In the last four bytes is stored
the value for the starting cluster number, and byte count number. Incidentally,
the space reserved for the root directory on a floppy disk is smaller, so only
224 entries are possible.
Because the root directory can only hold 512 entries, and modern
hard drives typically hold many thousands of files, it is necessary that a directory
structure be created. The mechanics of how to do this in DOS is the subject
of the next lesson, but it is absolutely necessary. Periodically someone will
encounter a problem saving a file, and when you investigate, it turns out they
were trying to save every file in the root directory and eventually ran out
of slots. In Windows 9x machines, this happens even more quickly because of
long file name support. If you noted above that only 8 bytes
are reserved for the file name in each entry, and if you realized that each
character requires one byte to describe it, you quickly see why DOS only allows
8 character file names. In Windows 9.x, you can use longer file names, but only
by using multiple directory entries for each long file name. It is not unusual,
therefore, to have a directory in Windows 9.x fill up when only 200-300 items
are stored, if long file names are used.
That is the technical reason for creating a directory structure.
There is also a practical reason, and that is that a good directory structure
can help you organize your data in useful ways. Imagine a company that stored
all of its documents in a “documents room”. Every day, people would
open the door, throw in a bunch of documents, and close the door again. One
day, you need to find a particular document, so you have to go into this room,
and look at each document one at a time until you find the one you want. Obviously,
this would take a lifetime to find, and is a really stupid way to save documents.
Instead, you would create a filing system, using file cabinets, each divided
into drawers, and in each drawer a bunch of hanging folders, and in each hanging
folder a number of manila folders, and in each of them a number of documents.
Then, when you wanted to find a particular document, you would look up in a
directory to see which filing cabinet it was in, then read the drawer labels
to see which drawer it was in, then read the labels on the folders, etc. until
you had the document. You might perform this task in only a few minutes if the
filing system was logical. Well, this is what you want to do with your hard
drive. Under the root directory, you create your top-level “directories”,
which are the equivalent of your filing cabinets. Then inside of each of these
you can create sub-folders (“drawers”), and in each of these sob-folders
you can create additional sub-folders (“hanging folders”), etc. Then,
when you need to find the memo you wrote to your boss in October of 1998, it
will be easy to find it.