FATFS文件系统详解(二)

电子说

1.2w人已加入

描述

4.4 访问FAT条目

FAT区由一条条FAT条目构成,关于 FAT[N] 对应的条目具体位置计算如下:

ASCII

格外需要注意的是,不同格式,对应的FAT条目的长度和格式不一样:

此外对于FAT32格式,高4位是保留位,只有低28位有效!

具体如下图所示:

ASCII

4.5 文件与簇之间的关系

那么文件和簇之间的相互关系又是怎样的呢?我们又是如何准确的找到存放在flash上的文件的呢?接下来让我们看下文件与簇之间的关系映射。

在FAT卷上文件通过目录管理,==目录是一个32字节数组组成的目录条目结构==,此目录结构包含:文件名、文件大小、时间戳以及文件所在的第一个簇号。

簇号为0和1的簇被保留,由参数BPB_RootClus可知,有效簇从第2号簇开始。==FAT2对应数据区的第一个簇==。

因此第N个簇的位置计算公式如下:

FirstSectorofCluster = DataStartSector + (N - 2) * BPB_SecPerClus

==每个条目所在的位置,对应一个簇。当文件长度大于一个簇长度时,条目内的值为下一个条目的索引,直到文件所在的最后一个簇,由此构成簇链!文件所在的最有一个簇所对应的FAT条目内的值由一个特殊的值(EOC)组成,它永远不会匹配任何有效的簇号==,如下:

FAT12: 0xFF8 - 0xFFF (typically 0xFFF)

FAT16: 0xFFF8 - 0xFFFF (typically 0xFFFF)

FAT32: 0x0FFFFFF8 - 0x0FFFFFFF (typically 0x0FFFFFFF)

存在一些特殊的值被用来做损坏簇的标记,如下:

FAT12: 0xFF7

FAT16:0xFFF7

FAT32:0xFFFFFFF7

不过此处需要注意,在FAT12/16系统上,上述特殊值绝不会和任何有效簇匹配,但是在FAT32上有可能,因此为了防止混淆,你在创建FAT32系统的时候应该避免这种情况发生!因此FAT32系统上簇的上限为268435445(大于256M个簇)

FAT条目初始化的时候,FAT[2] 及以后的数据应被初始化为0,指示未被使用处于空闲状态,如果值不为0,则意味着簇被损坏或被使用状态。在FAT12/16系统上,空闲簇的数量未被记录,而在FAT32系统上,FAT32支持FSInfo结构体,里面记录了空闲簇的数量。

==关于FAT[0]和FAT[1]:==

此两个保留的条目,没有与任何簇有联系;不过具有其他意义,如下:

FAT12: FAT[0] = 0xF??; FAT[1] = 0xFFF;

FAT16: FAT[0] = 0xFF??; FAT[1] = 0xFFFF;

FAT32: FAT[0] = 0xFFFFFF??; FAT[1] = 0xFFFFFFFF;

FAT[0]中的?? 与 BPB_Media 相同;

FAT[1] 记录了错误历史记录:卷脏标志(FAT16:bit15、FAT32:bit31),系统在启动的时候清除此位,正常关闭的时候恢复。

如果此位已经清除,表明上次未被正常关闭,可能存在逻辑卷错误;硬件错误标志(FAT16:bit14、FAT32:bit30)当出现无法恢复的读写错误时清除,表明需要进行全面检查。

==关于FAT区域,有两个重点注意事项:==

第一个是FAT的最后一个扇区可能没有被完全使用。在大多数情况下,FAT在扇区的中间结束。FAT驱动程序不应该对未使用的区域做出任何假设。在格式化卷时,应该用零填充它,并且在此之后不应更改它。

另一个是BPB_FATSz16/32可以指示比卷需要的值大的值。换句话说,未使用的扇区可以跟随每个FAT。这可能是数据区域对齐或其他原因导致的。同时,在格式化时这些扇区也会被用零填充。

下表展示了不同FAT类型中FAT值所对应的含义解释:

ASCII

4.6 FSInfo扇区结构及备份引导扇区

此部分内容只在FAT32系统上存在,对于FAT12系统FAT区域大小最大6KB,对于FAT16系统FAT区域最大128KB,但是在FAT32系统上FAT区域通常上达数MB,这是因为FAT32系统支持FSInfo数据结构。

在FAT32系统上新增FSInfo数据结构的原因是:在FAT12/16系统上,想要知道flash上剩余的簇数需要扫描整个FAT区才能计算出来,但随着flash容量的不断扩大,扫描花费的时长越来越长,为了避免扫描浪费过多的时间,因此在FAT32系统上增加了FSInfo结构,用于记录flash上剩余的簇数。

FSInfo数据结构如下:

| 字段名 | 偏移 | 大小 | 描述 |

| — | — | — | — |

| FSI_LeadSig | 0 | 4 | 固定值为0x41615252,头部签名 |

| FSI_Reserved1 | 4 | 480 | 保留区域,采用0x00覆盖 |

| FSI_StrucSig | 484 | 4 | 固定值为0x61417272,也是一个签名 |

| FSI_Free_Count | 488 | 4 | 记录了空闲的簇数,如果这个值为0xFFFF FFFF,则表示不知道具体的空闲簇数 |

| FSI_Nxt_Free | 492 | 4 | 提示驱动程序应该从此参数提示的簇开始寻找空闲的簇,通过此参数便可以不用从FAT区头开始寻找下一个空闲簇了,节省了大量时间;如果此参数为0xFFFF FFFF,则驱动程序应该从头部(2号簇)开始寻找空闲簇|

| FSI_Reserved2 |496 | 12 | 保留区域,采用0x00覆盖 |

| FSI_TrailSig | 508 | 4 | 固定值0xAA550000,尾部签名 |

注意:当扇区大小大于512字节时, 剩余空间采用0x00填充

4.7 FAT目录

FAT目录分为长文件名目录(LFN)以及短文件名目录(SFN),长文件目录是在短文件名目录上的一个扩展,具体采用长文件名还是短文件名由读取FAT文件系统的操作系统决定,如windows;设置长文件名时短文件名也被设置,具有兼容性。

此外,有一个很重要的概念:在FAT文件系统上目录也是一个文件,只是此文件的属性不一样而已。

在所有目录中,有一个比较特殊的是根目录,且根目录作为顶层目录必须存在。

在FAT12/16系统中,根目录不是一个文件,且放在根目录区,根目录的最大条目数由 BPB_RootEntCnt 参数指示;

在FAT32系统中,根目录与子目录没有什么区别,且根目录的起始簇由 BPB_RootClus 参数指示。

根目录与子目录的另外一个区别是,根目录不包含 . .. 此两个点目录,且它可以包含卷标(具有ATTR_VOLUME_ID属性的条目)

4.7.1 SFN 短文件名目录

目录条目结构如下:

ASCII

ASCII

关于目录结构的第一个字段 DIR_Name 的第一个元素 DIR_Name[0] 在目录表中有着特殊作用,如下:

当此值为 0xE5 时,代表此目录条目未被使用(或已废弃)

当此值为 0x00 时,也代表此目录条目未被使用;此外还提示后续目录条目也未被使用,因为后续的目录条目 DIR_Name[0] 都会是 0x00

如果文件名的第一个字符为 0xE5 这个特殊值,则使用 0x05 替代。

这么设计的意义是什么呢?将 DIR_Name[0] 用作特殊字符,其目录在于方便文件删除!当我们删除一个文件的时候,文件系统并不会将此文件所对应的数据全部删除,因为那样太费时间了,也没有必要,而是直接将对应文件的目录项中的 DIR_Name[0] 修改为 0xE5 即可!

关于文件名字段 DIR_Name,在FAT文件系统中还有如下规定:

DIR_Name 字段的11字节的文件名分为两个部分:8 字节的主文件名 + 3字节的扩展名;

文件名中主文件名与扩展名中间的 . 被省略,不在此记录

如果主文件名长度不够,小于8字节,则使用 0x20 空格填充

用于设置文件名的字符也有限制,支持的字符有 ==0~9 A~Z ! # $ % & ‘ ( ) - @ ^ _ ` { } ~==

主文件名和扩展名中的(a~z)ASCII字符都会被转化成大写字符保存

以下为文件名存储示例:

ASCII

4.7.2 LFN长文件名

长文件名是文件名的另外一种存储方式,由于SFN短文件名具有长度、字符等限制,在一些场景下不能很好的满足需求,因此就需要使用到长文件名,关于长文件名的具体内容如下:

长文件名是一个具有特殊属性的目录条目。长文件名目录属性 DIR_Attr 字段的值 ATTR_LONG_NAME = (ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID) = 0x0F;

ASCII

关于长文件名的目录属性如下:

| 字段名 | 偏移 | 大小 | 描述 |

| — | — | — | — |

| LDIR_Ord | 0 | 1 | 序号(1-20),用来表示此条目属于长文件名序列条目中的第几条。且长文件名序列首条条目的值应& 0x40以进行标识! |

| LDIR_Name1 | 1 | 10 | 长文件名 第1 ~ 第5 字符(注意此处一个字符占两个字节) |

| LDIR_Attr | 11 | 1 | 长文件名属性,此值永远为 ATTR_LONG_NAME 0x0F

| LDIR_Type | 12 | 1 | 类型,必须为0 |

| LDIR_Chksum | 13 | 1 | 和校验 |

| LDIR_Name2 | 14 | 12 | 长文件名 第6 ~ 第11 字符(注意此处一个字符占两个字节) |

| LDIR_FstClusLO | 26 | 2 | 必须为0 |

| LDIR_Name3 | 28 | 4 | 长文件名 第12 ~ 第13 字符(注意此处一个字符占两个字节) |

关于长文件名,有以下几点重要概念:

一个文件一定有短文名SFN,但不一定有长文件名LFN

长文件名LFN字段中==仅包含文件名信息==,不包含其他内容,其他内容需要通过短文件名SFN查看

如果一个文件既有长文件名也有短文件名,则长文件名是其主要名字,而短文件名则为附加名字

==长文件名LFN条目在对应的短文件名SFN条目前面==

一个文件的长文件名最长255字符,对应最多20个长文件名LFN条目

长文件名简单理解起始就是存储一个字符串,因此没有类似SFN的限制,允许有空格、支持大小写、允许多个.符号等

LFN条目文件名长度不够,仍然采用0x20填充

下图是官方关于一个名为 “MultiMediaCard System Summary.pdf” 的长文件名在flash上的长文件名条目,如下所示,一眼没看明白也没关系,后文有实例说明,对长文件名有概念了就行!

ASCII

关于长文件名的checksum字段和计算,算法如下:

uint8_t create_sum (const DIR* entry)

{

int i;

uint8_t sum;

for (i = sum = 0; i < 11; i++) { /* Calculate sum of DIR_Name[] field */

sum = (sum >> 1) + (sum << 7) + entry->DIR_Name[i];

}

return sum;

}

4.7.3 LFN系统对于SFN的兼容

在使用LFN长文件名的系统中,会自动生成SFN短文件名已确保此文件在短文件名的文件系统中可使用。同时为了防止生成的短文件名冲突,SFN的生成采用 名称+数字后缀+扩展 的格式,同时采用以下规则生成SFN:

小写自动转大写

如果存在空格,则删去空格,设置有损转换标识

已.开头的文件删除头部的.,并设置有损转换标识

存在多个.的文件名,仅保留最后一个作为文件名与扩展的分隔,并设置有损转换标识

其他不支持的字符,采用_代替,并设置有损转换标识

文件名如果是Unicode编码,则转化为ANSI/OEM编码;不能转换的字符采用_代替,并设置有损转换标识

长度超过8字节的部分,截断,并设置有损转换标识

扩展名字段超过3字节的,截断,并设置有损转换标识

有损转转换标识为:~,ASCII值为0x7E,十进制126

示例如下:

ASCII

至此,FAT文件系统的理论部分已经描述完了,接下来我们继续使用winhex对数据进行分析。

5.分区分析

继续回顾我们一开始的这张布局图

ASCII

5.1 保留分区分析

保留分区为第一个分区,其中引导扇区位于保留分区的第一个扇区。

根据 4.3 章节计算结果可知,保留分区起始地址为 0x00,大小 0xC00

保留分区数据如下,保留分区内最重要的内容即为引导扇区,除引导扇区外,其他剩余空间全部保留,采用0x00覆盖。关于引导扇区已在 4.2 章节详细分析,此处不再做介绍。

ASCII

5.2 FAT区分析

根据 4.3 章节描述,FAT区的起始地址为 ==0xC00==,大小为 ==0x3B400==,此外存在两个FAT区,FAT1和FAT2,起始地址分别为:==0xC00==、==0x1E600==,对应地址数据如下:

FAT1 数据:

ASCII

FAT2 数据如下:

ASCII

==由于此处采用FAT16格式,所以每个FAT条目占据两个字节!==

根据上述数据进行分析:

确认 FAT2 为 FAT1 的备份;

存在5个FAT条目其中 FAT[0] 和 FAT[1] 为保留条目,FAT[0] 的内容与 BPB_Media 媒体类型字段一致,FAT[1] 用来记录错误历史记录 (详见 4.5 章节描述)

==根据4.5章节描述,FAT2对应数据区的第一个簇==,又FAT[2]、FAT[3]、FAT[4] 数据均为 0xFF,表明存在三个文件,且每个文件的大小小于等于一个簇的空间;且分别存放在数据区第1到第3个簇上!

此处可能大家会由疑问,刚刚格式化的sd卡为什么会存在文件内,其实这个是系统文件,格式化后自带的,默认是隐藏的,只有使用winhex才能看到,也就是对应的System Volume Information文件夹。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分