NTFSボリュームのディスク上のMFTを解析するコードを書いています。これは簡単ですが、ある特定のコーナー ケースが私の目に留まり、インターネット上のどこにも明確な答えが見つかりません。
NTFS の通常のファイルでは、単一のファイルに複数の MFT レコードを含めることができます。これは、ファイルが単一のレコードに収まりきらないほど多くの属性を持っている場合です (たとえば、ファイルに多くのハード リンクがある場合、または多くの多数の代替データ ストリームがある場合は $DATA 属性)。
参照番号 0 の $MFT ファイルには、MFT 自体のデータ実行が保持されます。通常、これは子を持たない単一のレコードです。$MFT ファイルに子レコードを含めることはできますか? 可能であれば、どこでそれらを見つけることができますか? これらの子レコードは、ディスク上のどこにあるかを知るために $MFT を解析しなくても確実にアクセスできるように、非常に低い参照番号で保存する必要がありますか?
と呼ばれる特別なタイプの属性があります$ATTRIBUTE_LIST。ファイルまたはディレクトリは最大 65536 個の属性を持つことができ、単一の MFT エントリに収まらない可能性があります。基本的に、自分自身を除くすべてのファイルの属性のリストが含まれています。リスト内の各エントリには、属性タイプと、属性を見つける場所の MFT 参照が含まれています。それが、ファイル レコード ヘッダーのベース ファイル参照フィールドの目的です。
リストが MFT エントリに対して大きくなりすぎると、属性が非常駐になる可能性があり、リストは属性のデータ実行を解釈することによって検出されます。
のタイプ$ATTRIBUTE_LISTは 32 であるため、通常は属性の直後に配置され、$STANDARD_INFORMATIONより大きなタイプの属性 ($FILE_NAMEまたは など$DATA) が含まれます。
ファイルが非常に断片化されると、$DATA属性実行リストが 1 つの MFT エントリに収まらなくなります。これは、属性を複数のエントリ$ATTRIBUTE_LISTに格納するために使用されるケースでもあります。$DATA
$MFT割り当てアルゴリズムはそれを防ぐように設計されているため、エントリにこの問題が発生することはめったにありません。しかし$MFT、ボリュームの が非常に断片化した場合、複数のエントリを格納することができます$DATA。
tl;dr: はい。私はこれが何のためにあると信じていERROR_DISK_TOO_FRAGMENTEDますSTATUS_MFT_TOO_FRAGMENTED。
詳しく説明するには:
MFT ファイルには、確実に子レコードを含めることができます。このようなものを作成する必要がある場合は、開いて\$MFT(物理ボリュームを台無しにしたくない場合は RAM ディスクで作成してください...)、FSCTL_MOVE_FILE各エントリを、ボリュームの最初と最後を交互に繰り返します。MFT を大幅に断片化し$ATTRIBUTE_LIST、16 の初期レコードのうち最後の 4 レコードに収まらなくなるような を生成します。後のスロットにオーバーフローします。
ただし、論理的には、MFT はブートストラップ可能である必要があります。したがって、エントリによって記述された各子は$ATTRIBUTE_LIST、前のエクステントのスロットにある必要があるとしか結論付けられません。そのため、ボリュームには MFT を拡張するのに十分な空き領域があるが、MFT の次のエクステントを記述する空きスロットがないという状況に陥る可能性があります。これは、ドライバーが戻ってくる状況の 1 つだと思いますSTATUS_MFT_TOO_FRAGMENTED。
このための効率的なパーサーを書いて頑張ってください。かなり面倒です。
(nb 可能ですが、$ATTRIBUTE_LISTそれ自体も断片化するのは困難です。しかし、その実行リストは単一のレコード内に収まらなければならないことを読んだので、これは断片化の数に厳しい制限を課します。)