我正在编写一些代码来解析 NTFS 卷中磁盘上的 MFT。这很简单，但是一个特殊的极端案例引起了我的注意，我在互联网上的任何地方都找不到明确的答案。
对于 NTFS 中的普通文件，如果文件的属性多于单个记录（例如，如果文件有许多硬链接，则有许多 $FILE_NAME 属性，或者许多$DATA 属性，如果它有许多备用数据流）。
参考号 0 处的 $MFT 文件保存 MFT 本身的数据运行。通常它是一个没有孩子的单一记录。$MFT 文件是否有可能有子记录？如果可能的话，你怎么知道在哪里可以找到它们？这些子记录是否必须以非常低的参考编号存储，以便您可以可靠地获取它们，而不必已经解析 $MFT 以知道它们在磁盘上的位置？
有一种特殊类型的属性称为$ATTRIBUTE_LIST。一个文件或目录最多可以有 65536 个属性，它们不可能适合单个 MFT 条目。它基本上包含除了他自己之外的所有文件属性的列表。列表中的每个条目都包含属性类型和查找属性的位置的 MFT 参考。这就是文件记录头中的基本文件引用字段的用途。
如果列表对于 MFT 条目来说太大，则属性可能会变得非常驻，并且将通过解释属性的数据运行来找到列表。
因为 的类型$ATTRIBUTE_LIST是 32，所以它通常放置在$STANDARD_INFORMATION属性之后，并且将包含更大类型的属性（如$FILE_NAME或$DATA）。
当文件变得非常碎片化时，$DATA属性运行列表将不适合单个 MFT 条目。这也是$ATTRIBUTE_LIST将用于将$DATA属性存储在多个条目中的情况。
该$MFT条目很少有这个问题，因为分配算法旨在防止这种问题。但是如果一个$MFT卷的 a 变得非常分散，它可以有多个条目来存储它$DATA。
tl;博士：是的；我相信这就是ERROR_DISK_TOO_FRAGMENTED/STATUS_MFT_TOO_FRAGMENTED的用途。
详细说明：
MFT 文件肯定有子记录。如果您需要像这样构建一个，只需打开\$MFT（在 RAM 磁盘上进行，除非您想弄乱物理卷......）然后FSCTL_MOVE_FILE每个条目，在卷的开头和结尾之间交替。您将严重分割 MFT 并导致它生成一个$ATTRIBUTE_LIST，以至于它甚至不再适合 16 个初始记录中的最后 4 个。它会溢出到后面的插槽中。
然而，逻辑表明 MFT 需要是可引导的。因此，我只能得出结论，$ATTRIBUTE_LIST条目描述的每个孩子都必须位于前一个范围的插槽中。因此，可能会遇到卷有足够的可用空间来增长 MFT，但没有可用插槽来描述 MFT 的下一个范围的情况。我认为这是司机会返回的一种情况STATUS_MFT_TOO_FRAGMENTED。
祝你好运为此编写一个有效的解析器，这相当乏味。
（nb 也可以自行分段，但更难$ATTRIBUTE_LIST。但我读到它的运行列表必须适合单个记录，因此这对分段数量施加了硬性限制。）