ファイルシステムに直接触れるには、セクタから読み出した情報をメモリ上に展開し、その内容を解析していく必要があります。
つまり、ドライブから取得したセクタデータをバッファへ読み込み、そのメモリ領域に対して、構造体やポインタを使いながら解析していく流れになります。
ここで重要なのは、通常のアプリケーション開発で行うような、オブジェクトを実体化して各メンバを操作する手法とは少し考え方が異なる点です。
ファイルシステム解析では、先にメモリ上に生のバイナリデータがあります。
そのバイナリデータを、あとから構造体として解釈していきます。
つまり、構造体を作ってデータを入れるのではなく、すでに存在するメモリ上のデータを、構造体として読み解くという考え方になります。
このような処理でよく使われる考え方の一つに、可変長構造体があります。
可変長と聞くと、C++のvectorのような構造を思い浮かべるかもしれません。
しかし、ファイルシステム解析で扱う可変長構造体は、それとは性質が異なります。
vectorは、メモリ上で要素数を増減できる便利なコンテナです。
ただし、それはあくまでプログラム上のオブジェクトとして可変長に振る舞っているものです。
ファイルシステム上に記録されているデータ構造を、そのままvectorとして扱うことはできません。
もちろん、セクタデータを読み込むためのバッファとして、あらかじめresizeしたvectorを使うことはできます。
しかし、push_backやemplace_backのような操作で、ファイルシステム上の構造そのものを扱うわけではありません。
ファイルシステム解析で必要になるのは、メモリ上に展開されたバイナリデータを、そのまま構造体として解釈する考え方です。
では、C言語で可変長構造体をどのように表現するのでしょうか。
古くから使われてきた方法として、構造体の最後に、要素数1のunsigned char配列を置く手法があります。
たとえば、構造体の最後に次のようなメンバを置きます。
unsigned char data[1];
unsigned charは、純粋なバイト列を扱うための器として使えます。
このdata[1]は、単なる1バイトの配列というより、その先に続く可変長データの開始位置を示す目印として使われます。
重要なのは、この配列が構造体の最後に置かれている点です。
構造体の最後に可変長データの開始位置を置くことで、固定長のヘッダ部分を読み取ったあと、その直後に続くデータ領域を別の構造として解釈できるようになります。
たとえば、ヘッダ構造体の中にサイズ情報やオフセット情報が含まれている場合、その情報をもとに、ヘッダの後ろに続く属性データや可変長データを読み解いていきます。
このとき、ポインタを進めたり、再解釈キャストを行ったりして、メモリ上の別の位置を別の構造体として扱います。
つまり、ヘッダに可変長データの開始位置を示すメンバがある場合、その先に別の構造体や属性情報が連続して配置されている可能性があります。
そのため、サイズ情報やオフセット情報を確認しながら、次の構造へ進んでいく必要があります。
このような処理では、構造体全体のサイズにも注意が必要です。
最後にunsigned char data[1]を置く方式では、sizeofで取得される構造体サイズには、その1バイト分も含まれます。
そのため、固定長ヘッダ部分だけのサイズを求めたい場合は、その1バイト分を差し引くか、より安全にはoffsetofを使って可変長メンバの開始位置を求めます。
可変長部分の実際のサイズは、構造体内に記録されているサイズ情報や、ファイルシステム側の管理情報から判断します。
なぜ、このような構造が使われるのでしょうか。
それは、ドライブがセクタ単位でしか情報をやり取りしないためです。
ドライブは、ファイル名やフォルダ構造を理解しているわけではありません。
ただ、指定されたセクタのバイト列を読み書きしているだけです。
そのバイト列を、ファイルシステム側がヘッダ、属性、データ、管理情報として解釈しています。
つまり、セクタ上のデータは、メモリ上に展開された瞬間に、構造体として読み解く対象になります。
パソコンやスマートフォンが動作しているこの瞬間にも、内部ではこのようなバイナリ構造が読み書きされ、ファイルシステムが管理されています。
データ復旧では、その仕組みを逆方向から読み解きます。
セクタを読み出し、メモリに展開し、構造体として解釈する。
そして、壊れたファイルシステムの中から、まだ残っている管理情報や実データを探し出す。
この考え方こそが、ファイルシステム解析の基本になります。
