FAT32学习笔记（二）长文件名的处理，文件内容的查找，目录的处理

长文件名的处理

在FAT32的directory entry里，所预留的文件名的长度是8.3格式的，也就是说，文件名是8个字符，后缀名是3个字符，长于这个的就被认为不合法。不太确定这个规定是从FAT12开始的，还是从FAT16开始的，总之在FAT32里依旧有这个限制的影子，但FAT32同样也有机制去处理更长的文件名。

下面是按照第一篇文章一样的方式创建出来的FAT32文件格式的image文件，然后在里面创建一个名字巨长无比的文件，就叫abcdefghijklmnopqrstuvwxyz.txt1234吧，这个是远远突破了8.3格式的要求了，下面是它在FAT32 image里的样子，如图：

至于为什么会找到0x9e000这个地址，请看FAT32学习笔记（一）里的介绍。

从这个截图里可以看到，在0x9e060的地方和文件名非常相似，所不同的是创建的文件名是小写，而image里所存储的却是大写，而且，在不考虑长文件名支持的情况下，这个文件读出来会是”ABCDEF~1.TXT”，相信很多人都会有一种特别熟悉的感觉，尤其是这个“xxxx~1.xxx”中的“~1”。接下来就是FAT32中对长文件名的格式定义：

在data area里，每32 Bytes是一个directory entry。其中，

offset 0x0 - 0xA是DIR_name，前8个bytes是文件名，后3个bytes是后缀；

offset 0xB是DIR_attr，该bytes上每个bit的定义如下：

ATTR_READ_ONLY，0x01

ATTR_HIDDEN，0x02

ATTR_SYSTEM，0x04

ATTR_VOLUME_ID，0x08

ATTR_DIRECTORY，0x10

ATTR_ARCHIVE，0x20

ATTR_LONG_NAME, ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID

offset 0xC，reserved

offset 0xD，DIR_CrtTimerTenth，表示文件创建时间的，这里不太关心，所以不详细解释

offset 0xE - 0xF, DIR_CrtTime,

offset 0x10 - 0x11, DIR_CrtDate,

offset 0x12 - 0x13, DIR_LstAccDate,

offset 0x14 - 0x15, DIR_FstCusHI，表示该文件内容所在的簇的高2个bytes，它将和DIR_FstClusLO一起凑成一个4bytes的数，在这个簇里就能找到该文件的内容。

offset 0x16 - 0x17, DIR_WrtTime，

offset 0x18 - 0x19，DIR_WrtDate，

offset 0x1A - 0x1B，DIR_FstClusLO，和前面的DIR_FstCusHI一起作为文件内容的寻址数。

offset 0x1C - 0x1F，DIR_FileSize，文件大小。

注意offset 0xB，DIR_Attr，如果这里是0xF，就表示该entry是LONG_NAME的一部分，此时它的bytes含义就会发生变化

LONG_NAME部分的directory entry Bytes定义如下：

offset 0x0，LDIR_Ord，表明该entry在一串LONG_NAME entry中的顺序。如果bit6为1，则该串LONG_NAME entry以这个entry结束。

offset 0x1 - 0xA, LDIR_Name1，全部是character，

offset 0xB，LDIR_Attr，必须是ATTR_LONG_NAME，

offset 0xC, LDIR_Type，如果为0，表明该entry是LONG_NAME entry的一部分，

offset 0xD, LDIR_Chksum，校验和

offset 0xE - 0x19, LDIR_Name2,全部是character，

offset 0x1A - 0x1B，LDIR_FstClusLO，在LONG_NAME entry里没有意义，它存在的意义只是用来和老的tool兼容，

offset 0x1C - 0x1F，LDIR_Name3，全部是character。

在了解了长文件名directory entry的定义之后，就很容易从刚才的截图中看出来“abcdefghijklmnopqrstuvwxyz.txt1234”是如何存储在FAT32 image里的了。下图是一个简单的总结：

文件内容的查找

在上图中，用黄色表示出来的会组成一个4 bytes的数，图中会组合成0x00000003，表示该entry所表示的文件，它的内容在簇3里，也就是第一幅图中，0x9e200的部分。至于簇3的地址如何计算，还请参考FAT32学习笔记（一）里的内容。

目录的处理

使用如下命令在FAT32 image里创建一个目录，就能很清楚的知道“目录”这个东东到底是怎么一回事了

sudo mount test.img /mnt/

cd /mnt/

sudo mkdir test

cd /test

touch 1.txt

touch 2.txt

echo abcdefg >> 1.txt

echo 1234567 >> 2.txt

cd /tmp

sudo umount /mnt/

hexdump -C test.img

得到如下结果：

从0x9e080开始，是这次新创建的test目录，还是按照刚才的长文件名的处理方式，能够知道该目录的内容在簇4里，也就是0x9e400的地方。在0x9e400的地方，同样的按照长文件名的处理方式，能够找出来如下的directory entry：

0x9e400，一个directory entry，表示的目录是“.”，从该directory entry里可以看到，它的内容在簇4里，也就是本身，因此，目录“.”表示当前目录。

0x9e420，一个directory entry，表示的目录是“..”，从该directory entry里可以找到它的内容在簇0里，然而，在FAT32规范里，Data Area是从簇2开始的，到底如何处理有待研究。

0x9e440，两个directory entry，表示文件1.txt，它的内容在簇5里，也就是0x9e600。

0x9e480，两个directory entry，表示文件2.txt，它的内容在簇6里，也就是0x9e800。

按照对应的地址去找，都能看到相应的内容。

这里还有另外一个问题：目录“.”和目录“..”是FAT32规范的内容，还是Linux自己所定义的？在windows的系统里，应该是没有这样的内容的。等下次在windows系统里用U盘做实验，拿到ubuntu上来观察就可以解答这个疑惑了。到时候再更新这篇文章。

（还有另外一个方式，把这个test.img放到host machine，挂载到windows的虚拟机上，这样就不需要U盘了。而且，我的U盘用了好久，里面全都被写满了，看起来好凌乱啊，没有这种image看起来清晰）。