|
|
FAT32存储原理：
FAT32是个非常有功劳的文件系统，Microsoft成功地设计并运用了它，直到今天NTFS铺天盖地袭来的时候，FAT32依然占据着Microsoft Windows文件系统中重要的地位。FAT32最早是出于FAT16不支持大分区、单位簇容量大以致空间急剧浪费等缺点设计的。实际应用中，FAT32还是成功的。
FAT32与FAT16的原理基本上是相同的，图4.3.12标出了FAT32分区的基本构成。
图4.3.12 Fat32的组织形式
引导扇区 其余保留扇区 FAT1 FAT2(重复的) 根文件夹首簇 其他文件夹及所有文件 剩余扇区
1扇区 31个扇区 实际情况取大小 同FAT1 第2簇 不足一簇
保留扇区 ┗━━━━━━━━数据区━━━━━━━━┛
FAT32在格式化的过程中就根据分区的特点构建好了它的DBR，其中BPB参数是很重要的，可以回过头来看一下表4和表5。首先FAT32保留扇区的数目默认为32个，而不是FAT16的仅仅一个。这样的好处是有助于磁盘DBR指令的长度扩展，而且可以为DBR扇区留有备份空间。上面我们已经提到，构建在FAT32上的win98或win2000、winXP，其操作系统引导代码并非只占一个扇区了。留有多余的保留扇区就可以很好的拓展OS引导代码。在BPB中也记录了DBR扇区的备份扇区编号。备份扇区可以让我们在磁盘遭到意外破坏时恢复DBR。
FAT32的文件分配表的数据结构依然和FAT16相同，所不同的是，FAT32将记录簇链的二进制位数扩展到了32位，故而这种文件系统称为FAT32。32位二进制位的簇链决定了FAT表最大可以寻址2T个簇。这样即使簇的大小为1扇区，理论上仍然能够寻址1TB范围内的分区。但实际中FAT32是不能寻址这样大的空间的，随着分区空间大小的增加，FAT表的记录数会变得臃肿不堪，严重影响系统的性能。所以在实际中通常不格式化超过32GB的FAT32分区。WIN2000及之上的OS已经不直接支持对超过32GB的分区格式化成FAT32，但WIN98依然可以格式化大到127GB的FAT32分区，但这样没必要也不推荐。同时FAT32也有小的限制，FAT32卷必须至少有65527个簇，所以对于小的分区，仍然需要使用FAT16或FAT12。
分区变大时，如果簇很小，文件分配表也随之变大。仍然会有上面的效率问题存在。既要有效地读写大文件，又要最大可能的减少空间的浪费。FAT32同样规定了相应的分区空间对应的簇的大小，见表12：
表12 FAT32分区大小与对因簇大小
分区空间大小 每个簇的扇区 簇空间大小
<8GB 8 4k
>=8GB且<16GB 16 8k
>=16GB且<32GB 32 16k
>=32GB 64 32k
簇的取值意义和FAT16类似，不过是位数长了点罢了，比较见表13：
表13 FAT各系统记录项的取值含义(16进制)
FAT12记录项的取值 FAT16记录项的取值 FAT32记录项的取值 对应簇的表现情况
000 0000 00000000 未分配的簇
002~FFF 0002~FFEF 00000002~FFFFFFEF 已分配的簇
FF0~FF6 FFF0~FFF6 FFFFFFF0~FFFFFFF6 系统保留
FF7 FFF7 FFFFFFF7 坏簇
FF8~FFF FFF8~FFFF FFFFFFF8~FFFFFFFF 文件结束簇
FAT32的另一项重大改革是根目录的文件化，即将根目录等同于普通的文件。这样根目录便没有了FAT16中512个目录项的限制，不够用的时候增加簇链，分配空簇即可。而且，根目录的位置也不再硬性地固定了，可以存储在分区内可寻址的任意簇内，不过通常根目录是最早建立的(格式化就生成了)目录表。所以，我们看到的情况基本上都是根目录首簇占簇区顺序上的第1个簇。在图4.3.12中也是按这种情况制作的画的。
FAT32对簇的编号依然同FAT16。顺序上第1个簇仍然编号为第2簇，通常为根目录所用(这和FAT16是不同的，FAT16的根目录并不占簇区空间，32个扇区的根目录以后才是簇区第1个簇)
FAT32的文件寻址方法与FAT16相同，但目录项的各字节参数意义却与FAT16有所不同，一方面它启用了FAT16中的目录项保留字段，同时又完全支持长文件名了。
对于短文件格式的目录项。其参数意义见表14：
表14 FAT32短文件目录项32个字节的表示定义
字节偏移(16进制) 字节数 定义
0x0~0x7 8 文件名
0x8~0xA 3 扩展名
0xB* 1 属性字节 00000000(读写)
00000001(只读)
00000010(隐藏)
00000100(系统)
00001000(卷标)
00010000(子目录)
00100000(归档)
0xC 1 系统保留
0xD 1 创建时间的10毫秒位
0xE~0xF 2 文件创建时间
0x10~0x11 2 文件创建日期
0x12~0x13 2 文件最后访问日期
0x14~0x15 2 文件起始簇号的高16位
0x16~0x17 2 文件的最近修改时间
0x18~0x19 2 文件的最近修改日期
0x1A~0x1B 2 文件起始簇号的低16位
0x1C~0x1F 4 表示文件的长度
* 此字段在短文件目录项中不可取值0FH,如果设值为0FH，目录段为长文件名目录段
说明：
(1)、这是FAT32短文件格式目录项的意义。其中文件名、扩展名、时间、日期的算法和FAT16时相同的。
(2)、由于FAT32可寻址的簇号到了32位二进制数。所以系统在记录文件(文件夹)开始簇地址的时候也需要32位来记录，FAT32启用目录项偏移0x12~0x13来表示起始簇号的高16位。
(3)、文件长度依然用4个字节表示，这说明FAT32依然只支持小于4GB的文件(目录)，超过4GB的文件(目录),系统会截断处理。
FAT32的一个重要的特点是完全支持长文件名。长文件名依然是记录在目录项中的。为了低版本的OS或程序能正确读取长文件名文件，系统自动为所有长文件名文件创建了一个对应的短文件名，使对应数据既可以用长文件名寻址，也可以用短文件名寻址。不支持长文件名的OS或程序会忽略它认为不合法的长文件名字段，而支持长文件名的OS或程序则会以长文件名为显式项来记录和编辑，并隐藏起短文件名。
当创建一个长文件名文件时，系统会自动加上对应的短文件名，其一般有的原则：
(1)、取长文件名的前6个字符加上"~1"形成短文件名，扩展名不变。
(2)、如果已存在这个文件名，则符号"~"后的数字递增，直到5。
(3)、如果文件名中"~"后面的数字达到5，则短文件名只使用长文件名的前两个字母。通过数学操纵长文件名的剩余字母生成短文件名的后四个字母，然后加后缀"~1"直到最后(如果有必要，或是其他数字以避免重复的文件名)。
(4)、如果存在老OS或程序无法读取的字符，换以"_"
长文件名的实现有赖于目录项偏移为0xB的属性字节，当此字节的属性为：只读、隐藏、系统、卷标，即其值为0FH时，DOS和WIN32会认为其不合法而忽略其存在。这正是长文件名存在的依据。将目录项的0xB置为0F，其他就任由系统定义了，Windows9x或Windows 2000、XP通常支持不超过255个字符的长文件名。系统将长文件名以13个字符为单位进行切割，每一组占据一个目录项。所以可能一个文件需要多个目录项，这时长文件名的各个目录项按倒序排列在目录表中，以防与其他文件名混淆。
长文件名中的字符采用unicode形式编码(一个巨大的进步哦)，每个字符占据2字节的空间。其目录项定义如表15。
表15 FAT32长文件目录项32个字节的表示定义
字节偏移
(16进制) 字节数 定义
0x0 1 属性字节位意义 7 保留未用
6 1表示长文件最后一个目录项
5 保留未用
4 顺序号数值
3
2
1
0
0x1~0xA 10 长文件名unicode码①
0xB 1 长文件名目录项标志，取值0FH
0xC 1 系统保留
0xD 1 校验值(根据短文件名计算得出)
0xE~0x19 12 长文件名unicode码②
0x1A~0x1B 2 文件起始簇号(目前常置0)
0x1C~0x1F 4 长文件名unicode码③
系统在存储长文件名时，总是先按倒序填充长文件名目录项，然后紧跟其对应的短文件名。从表15可以看出，长文件名中并不存储对应文件的文件开始簇、文件大小、各种时间和日期属性。文件的这些属性还是存放在短文件名目录项中，一个长文件名总是和其相应的短文件名一一对应，短文件名没有了长文件名还可以读，但长文件名如果没有对应的短文件名，不管什么系统都将忽略其存在。所以短文件名是至关重要的。在不支持长文件名的环境中对短文件名中的文件名和扩展名字段作更改(包括删除，因为删除是对首字符改写E5H)，都会使长文件名形同虚设。长文件名和短文件名之间的联系光靠他们之间的位置关系维系显然远远不够。其实，长文件名的0xD字节的校验和起很重要的作用，此校验和是用短文件名的11个字符通过一种运算方式来得到的。系统根据相应的算法来确定相应的长文件名和短文件名是否匹配。这个算法不太容易用公式说明，我们用一段c程序来加以说明。
假设文件名11个字符组成字符串shortname[],校验和用chknum表示。得到过程如下：
- int i，j,chknum=0;
- for (i=11; i>0; i--)
- chksum = ((chksum & 1) ? 0x80 : 0) + (chksum >> 1) + shortname[j++];
如果通过短文件名计算出来的校验和与长文件名中的0xD偏移处数据不相等。系统无论如何都不会将它们配对的。依据长文件名和短文件名对目录项的定义，加上对簇的编号和链接，FAT32上数据的读取便游刃有余了。
|
|
|
|
|
|
|
|
|
|
