FATテーブル - @port139 Blog

ファイルのアロケーション情報を追跡する仕組みとしては、FATテーブルも利用されているわけですが、とりあえず FAT テーブルはこんな↓感じですね。FAT32 と同じく 4バイトで一つのクラスタを示すみたいですね。下記パターンでいくと、赤字部分の4バイトがクラスタ番号5の割り当て状況を示すということになるわけですかね。

F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

さて、ここでよくわからなくなりました。クラスタ番号 5 を利用している画像ファイルは、実際にはクラスタ5〜クラスタ31までを利用しているのですが、上記のテーブルではクラスタ 5 のみが割り当てということで、クラスタチェーンが記載されてないように見えます。
先ほどの「exFAT 構造解析」のページには、下記の記述があります。*1

3.3. FAT
　FAT の構造は FAT32 とほぼ同等。ただし、クラスタ番号は 28bit ではなく、32bitとなっている。
　FAT の個数は 1個。（TFAT を使う場合は 2個？）
　クラスタビットマップ、大文字変換テーブル、ルートディレクトリは、必ず FAT にクラスタの使用状況が書き込まれるが、それ以外のファイル・ディレクトリについては、分断が発生した場合だけクラスタ使用状況が書き込まれる。

実際にクラスタ5とクラスタ111の二カ所にフラグメントされたファイルを作成した場合の、FATテーブルはこんな↓のになります。クラスタ番号5のところでは、CL 111 をポイントする 6F 00 00 00 が設定されているようなのですが、~~その先となる CL 111 の位置が期待している内容と異なっている気がするんですけど。ひょっとしてオフセットの計算とか間違えているのかなぁ・・・~~オフセットの計算をおもいっきり間違えてました...orz
ちゃんと計算するとあってますね。

000: F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
005: 6F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
015: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
025: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
045: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
055: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
065: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
075: 00 00 00 00 00 00 00 00 FF FF FF FF 4F 00 00 00 50 00 00 00
080: 51 00 00 00 52 00 00 00 53 00 00 00 54 00 00 00 55 00 00 00
085: 56 00 00 00 57 00 00 00 58 00 00 00 59 00 00 00 5A 00 00 00
090: 5B 00 00 00 5C 00 00 00 5D 00 00 00 5E 00 00 00 5F 00 00 00
095: 60 00 00 00 61 00 00 00 62 00 00 00 63 00 00 00 64 00 00 00
100: 65 00 00 00 66 00 00 00 67 00 00 00 68 00 00 00 69 00 00 00
105: 6A 00 00 00 6B 00 00 00 6C 00 00 00 FF FF FF FF 00 00 00 00
110: 00 00 00 00 70 00 00 00 FF FF FF FF 72 00 00 00 73 00 00 00
115: 74 00 00 00 75 00 00 00 76 00 00 00 77 00 00 00 78 00 00 00
120: 79 00 00 00 7A 00 00 00 7B 00 00 00 7C 00 00 00 7D 00 00 00
125: 7E 00 00 00 7F 00 00 00 80 00 00 00

そもそも途中から変な（FF FF FF FF で括られたかのような）データが書き込まれているというのは、参加者の皆さんとなんぢゃらホイと悩んでいた部分になります。
このファイルが利用しているクラスタの利用状況とフラグメントは下記の配置になります。

仮説としては、フラグメントの終端はファイルサイズからわかるから、CL 111 の方には特にマークがないのではないか？というお話も出て、3カ所にフラグメントしたデータを作ってみようとなったわけですが....これがなかなかフラグメントされないんです（T_T)、何も考えずにファイルサイズを大きくしても再配置されてしまい逆に連続しちゃうんですよねぇ。まぁ賢いといえば賢いのかもしれませんが、実験するには意図的にクラスタを埋めておいてフラグメントが発生するような空きを作ってやる必要があるみたいなんですけど面倒なので試せていません。
ということで、たんにオフセット位置の計算間違えていただけなので、従来通りのクラスタチェインを追いかける方法ということで終了。

*1:改行位置を修正しています