File system management in FAT32 - Root directory management in FAT32

Root directory management in FAT32 partition

First here is a simple introduction of FDT:
All files/folders in FAT32 have corresponding file entries record in FDT, each file entry records important information of the file/folder (including: file or folder, long filename or short filename, start cluster, the create time, the capacity of file/folder and so on); the file system of operating system searches and localizes corresponding file/folder according to the file information in FDT of each partition. Under FAT32, size of each FDT is 32 bytes.

FAT32 root directory management includes management of files with short and long filename, and management of directories under root directory..

Management of files with short filename

Here is an introduction of management of files with short filename. Take an example of searching a file with short filename (test.txt) under root directory:

After reading or copying file test.txt in FAT32 partition, use utility software to view the BPB parameter of this partition:

From the chart we may know the start cluster of FDT is 2,
Here is a formula to calculate the FDT start sector:
FDT start sector = reserved sector number + sector number in each FAT * FAT number + (FDT start cluster - 2) * sector number of each cluster.
By the formula we may obtain the start sector of FDT = 8024 sector.
Examining 8024 sector content:

Thereto the first entry is the partition volume label, search test.txt in the FDT downwards, we can find registration entry of file test.txt in offset 003EB080.


Contents and the meaning of directory entry

Offset

bytes

Meanings

0 ~ 7

8

Filename

8 ~ 10

3

Extended name

11

1

Attribute byte

12 ~ 21

10

Reserved

22 ~ 23

2

Create time

24 ~ 25

2

File date

26 ~ 27

2

First cluster number

28 ~ 31

4

File length

Referring to the above table, from this FDT we may know: length of test.txt is 1270K; the start cluster number is 3rd cluster; from DBR, reserved sector number =38; FAT number = 2, each FAT length =3993 sectors, so the DATA start sector is 38+2*3993=8024; each cluster has 8 sectors. The corresponding sector of the 3rd cluster is 8032rd sector; this sector content is as following chart:

Now, let's search the sector position of next cluster:

In FAT32, record of each cluster in FAT takes 4 bytes, so the corresponding offset address of the 3rd cluster in FAT is: 4*3 the =12 bytes. Here is the FAT content:

The beginning 4 bytes of offset 12 is "04 00 00 00". Record of each cluster records cluster number of the next cluster; for high order is afterward, the next cluster of test.txt is stored in the 04 cluster in the partition; from offset 04*4=16, the first 4 bytes are "05 00 00 00", so the following files are saved in 05 cluster; by this method, the last cluster of the file in FAT cluster record is "FF FF FF 0F", then the FAT chain of test.txt comes to the end:

Management of the long filename file

File registration entry in FDT only reserved 8 bytes for the filename, 3 bytes for extension name (8.3 form for short), so we call it long filename file whose filename scales out.
In FAT32, if it is a short filename, then it can be saved in 32 byte dircotry entry of 8.3 form. When creating a long filename, there are following 3 principles for saving its corresponding short filename:

  • To take the first 6 characters of the long filename, add "~1" to form the short filename, its extension is unchanged;
  • If there has been a file with this filename, the number after "~" will be automatically increased, like"~2";
  • If there is invalid character of DOS and Windows3.x, use underline "_" to instead.

When some directory entry is used as a long filename directory, its attribute byte is 0FH, saving 13 bytes. A long filename needs more than one directory registration entries. By above storage method, in DOS or Windows3.x, we can only see its corresponding short filename, completely neglecting the long filename. When Windows application requests filename via operating system, Windows will assign different filenames according to attributes of the application - 16 bit application gets filenames of 8.3 form, 32 bit application gets long filenames.
Here's an example to analyze its management. To establish a "long file test long file1 long file2 long file3 long file4 long file5 long file6 long file7 long file8 long file9 long file10 long file11" file, the sector content in FDT is as following chart:

Analyze downwards long filename registration entry the file covers:

The FDT registration entry that last describes long filename is at the very beginning. Its attribute byte is "0FH" (in red frames). This is for distinguishing different file or directory registration entries. This registration entry with an end mark is the tail of long filename registration entry. To search downwards till the end of long filename registration entry, the closely followed first registration entry of the short filename is the corresponding short filename, which is described as"LONGFI~1TXT" (in red frames). From the first long filename before short filename, forwards to the end of long filename registration entry, it is corresponding long file. We can view the file's location and data in FAT table, DATA region via this file's short filename registration entry ("LONGFI~1TXT").
Problems and notes of long filename:
Although Windows95 and its superior system realize the compatibility of long filename and DOS, Windows3.x via above method, there are also several problems:

Problems and notes of long filename:
Although Windows95 and its superior system realize the compatibility of long filename and DOS, Windows3.x via above method, there are also several problems:

1.When changing the name of created long filename or deleting the filename, it will be lost, and the long filename directory entry space is also unable to be taken back. Because files track and manage mainly by short filename, the long filename exists adhering the short filename.

2.If run 16 bits application, when changing a filename, the corresponding long filename will be lost.

3.The directory registration entry that long filename uses must be continual, frequently creating and deleting long filename may cause massive disk fragments.

Therefore do not create long filename under root directory unless you have to. You can run disk defragment frequently, and recycle lost directory registration entry.