問題タブ [ntfs-mft]

ファイル内のフラグメント数が増えると、MFT レコードで使用されるバイト数が増加するのがわかります。予想どおり、1024 バイトのベース レコードの最後のバイトがすべて埋まるまで 8 ずつ増加してから、2 番目のレコードに分割されます。一見すると、答えは「1024 - headerlength」だと思うかもしれません。

ただし、その 2 番目のレコードが大きくなると、そのレコードのすべてのバイトが使用されるわけではありません。代わりに、1016 で最高になり、3 番目のレコードに分割されるときにレコードの 8 バイトが未使用のままになります (以下を参照)。ランの分割を続けると、3 番目のレコードも 1024 ではなく 1016 で分割されます。

通常、NTFS は MFT レコードの処理において非常に効率的であるため、この動作は非常に疑わしいものになります。バグのようなにおいがしますが、それが必要な理由ははっきりしていないと思います。

しかし、その後、4k MFT レコードの実験を開始しました ( format /L)。また、ベース レコードと拡張レコードの両方で、常に 4096 バイト全体が使用されます。

だから今、それは本当にバグのように見えます。バグが 1,000 レコードが 1016 で最高になるのか、それとも 4,000 レコードでも 4088 で最高にならないのかはわかりませんが、これらの最終バイトを予約する正当な理由があるか、そうでないかのどちらかです。

貴重なリソースを浪費するだけでなく、MFT レコードの「使用可能な」領域の計算が非常に複雑になります。この式は本当に「拡張レコードでない限り、レコードが MFT レコードのサイズまで大きくなると仮定し、4k レコードでない限り 8 を減算し、減算を行わない」というものですか? それとも、この動作は、ここに他の基準があることを意味していますか? トリックはありますか？

FWIW、これは分割直前の 1016 バイトのレコードです (ディスク エディタで表示)。属性マーカーの末尾 (FFFFFFFF 82794711) に続いて 8 つの空のバイトが表示されます。末尾の 02 00 は、MFT レコードによって使用される Updatebytes です。次の分割後、このレコードのサイズは半分になります。

Rust 内でhttps://docs.rs/mft/0.5.3/mft/index.html$MFTなどのライブラリを使用して、a を渡すのは簡単に思えます。ただし、現在のライブ システムでアクセスしようとすると、よりトリッキーに思えます。

mftクレートを使用して現在のドライブの NTFS $MFT を解析するにはどうすればよいですか?