Byte Range |
Info Stored |
1 to 8 |
Filename |
9 to 11 |
Extension |
12 |
Attributes (i.e. read-only, archive, hidden) |
13 to 22 |
Reserved bits for latter features |
23 to 24 |
Time Written |
25 to 26 |
Starting cluster |
29 to 32 |
File Size |
Interesting list isn't it? Some of the entries are self-explanatory. But there are two that are rather interesting. The first thing to look at is the Starting Cluster field. Some of you may have been wondering how the system translates cluster and sector indices into filenames and such. The answer is that for each file, there is a field in the FAT that indicates the first cluster of the file. The system would read that FAT entry and then find the starting cluster and read the file. Now the question is how does the system know when to stop reading? Furthermore, even before that, how does the system know where to read next after this cluster? The answer is that written within each cluster is the address of the next cluster that contains information from this file. So a computer reads the current cluster and checks to see if there are any other clusters after it. If there is, it skips to that cluster and reads it, and checks for the next one. This process repeats until it finds a cluster with no pointers. The CS majors reading this would recognize this as a Linked List implementation.
The other interesting feature of this table is that each directory entry (record in the FAT) uses 4 bytes to store the size of the file. This may not seem like much at first. But what it actually tells you is the maximum size possible for any single file. The fact that we use 4 bytes to store a file size tells us that the largest number that can be represented is 32bits (recall that there are 8 bits per byte). So what is the largest 32bit number? That would be 2^32 - 1. So a file can have a maximum of 2^32 -1 bytes, or 4 Gigabytes. This calculation is obviously done under the assumption that we are using FAT32.
The last two fields I'd like to take a look at are the filename field and the reserved bytes field. The interesting thing about the filename field is that DOS uses that field to perform undelete. When you erase a file in DOS, you aren't actually erasing the file. All you are doing is changing the first letter of the filename field into a special character. And as far as the file system is concerned, the file isn't there, and the next time a file is written to this cluster, the current file is erased. The way DOS performs an undelete is to simply change that first letter back to something else. That is why when you used undelete in DOS, it always asked for the first letter of the filename before it could restore the file. Mystery solved.
Now let me just make a quick mention of the reserved fields. The reserved fields didn't do much in FAT16, but it became rather useful in FAT32 and in NTFS. Since FAT32's cluster numbering used 32bit numbers instead of 16bit, as was the case in FAT16, the system needed two extra bytes to accommodate the added digits. Those two bytes were taken out of the reserved field. And in NTFS, compression attributes, some security information was also written into the reserved field of the FAT.
Before I move on, I'd like to point out a few of the other differences between FAT16 and FAT32. In FAT32, the root directory is unlimited in size. What this means is that you can have as many files and directories in C:\> as you'd like. In the days of FAT16, you could have a maximum of 255 directory entries. That means that if you had normal filenames of 8 letters + 3 extensions, you have a maximum of 255 directories + files. That may seem like more than you'd need to put in the root directory. And it probably is , if you had 8.3 filenames. But in Win95, the system can support long filenames. The trick is that Win95 combines multiple directory entries to support long filenames. So consider a file that's named "My English Paper". That is 16 letters long. So it takes 2 directory entries, at least. Actually, it takes 3 directory entries. It takes 2 for the long filename, and another one for the short 8.3 filename to be compatible with DOS and Win3.1. As you can see, long filenames can quickly deplete directory entries.
Another nice feature is that FAT32 has better FAT redundancy. Both FAT32 and FAT16 store two copies of the file allocation table on disk. But traditionally, the file system only read from one of them. In FAT32, the system could choose to read from either one, which provides a better failsafe for freak accidents involving corrupt file tables.
It is apparent that FAT32 is a superior file system then FAT16. Unfortunately, FAT32 is not supported by every operating system. The original version of Windows 95 couldn't read FAT 32. It wasn't until version B (OSR2) did Win95 gain that ability. And all versions of WinNT before 5.0 (named Windows 2000 or short Win2K) could not read FAT32 drives either.
- Xin Li - Page 1: Introduction to file systems
Page 2: This Page
Page 3: New Technology File
System (NTFS)
Page 4: File Auditing / Data
Recovery / Conclusion
|