051 調査結果を補足しましょう
●051 調査結果を補足しましょう
真夜中にふと気が付いた。どうやら寝落ちしていたようだ。行き詰まった感じがする。こういうときは分かっていることを整理して、状況を出来る限り冷静に見直すべきですね。
アロケーションファイルとＨＤＤの状態を可視化してみましょう。
アロケーションファイルは 3A35h 個のブロックからなり、１ブロックは 4KB なので 3A35h * 4096 * 8 = 488275968 ビットある。各ビットの１／０で、対応するアロケーションブロックの使用中／未使用を示すのでしたね。
この内、1D1Fh 以降は未使用と判明しているので、0h 〜 2000h の範囲を表示する。作図の都合で、横 256 縦 128 に収めるため、１ポイントで 8192 ビット分を表す。
8192 ビットが全て０の場合は青色（...っぽい色）、全てが１の場合は灰色、その中間は適当に緑とか、水色とかで。そうして作成したのが、次の Fig.F1 です。大きな図は i735107 です（...図をクリックして URL のところを書き換えてみてみん？）。
横軸がアロケーションファイルのブロック番号で 0h 〜 2000h です。アロケーションファイルのブロック番号 0h とは、アロケーションブロックの #1 のことです。これ！混乱しないようにね。
縦軸は 0 〜 127 あり、左下のポイント (0h, +0) から上に向かって続き、左上のポイント(0h, +127) の次は、(20h, +0) となりますです。20h * 256 = 2000h ですよ。
0h 〜 1601h は使用中が多いと把握していましたが、詳しくみれば、0h 〜 B00h と B01h 〜 1601h では状況が違ってました。削除してしまったファイルは B01h 〜 1601h にもあったのかも。小さ目なファイルですけど。
あと、0h 〜 B00h の範囲はほぼ全て使用中で、削除ファイルがほとんど無いのは、ああ確かに！、と思い当たることがあります（...だが、説明は謹んで略させて頂きます）。
＊＊＊
友「ポイントって、200 円につき１ポイント貰えるポイント？」
私「ち、違うよ！（...ポイントではなくて、ピクセルの方が良かったかも）」
＊＊＊
次に、アロケーションファイルでは０だが、アロケーションブロックにはデータが残っているブロックを示します。次の Fig.F2 です。縦軸・横軸は Fig.F1 と同じです。大きな図は i735109 です。
うーむ。B01h 〜 1601h の範囲の未使用のブロックは、ほぼ全て削除ファイルのデータですね。あ、橙色が未使用だがアロケーションブロックにデータがあるブロックです。8192 ビット分のうち、１個でも該当すれば橙色にしています。青色と灰色は Fig.F1 と同じで、未使用と使用中のブロックです。B01h 〜 1601h でも少しだけ青色のポイントが見えます。偶然にゼロが続くファイルがあったのでしょうか。
小さめのファイルって何でしょうか。測定器の制御用スクリプトやパラメータファイルかも。これらも復活させたいファイルではありますが、1602h 〜 1D1Eh に注目すべきであることには間違いないですね。
＊＊＊
0h 〜 40h の範囲を細かく見てみましょう。アロケーションブロックの #0 はボリュームヘッダで、#1 〜 #3a35h はアロケーションファイルでしたが、その他は何でしょうか。
ボリュームヘッダの 470h〜、4C0h〜、510h〜、560h〜、5B0h〜 には、５つの特殊なファイルに関する情報が格納されている。470h〜 はアロケーションファイルで、510h〜 はカタログファイルでしたね（[025]と[030]で調べました）。それと、カタログファイルのリーフノードを探索して、0h 〜 40h の範囲にあるファイルをリストアップする。３つ見つかった。
これらのファイルのアロケーションブロック番号を次に示します。
_____#0h 〜 _____#0h : ボリュームヘッダ (0h,0,0)
_____#1h 〜 __#3A35h : アロケーションファイル (0h,0,1)
__#3A36h 〜 __#3A36h : ".journal_info_block" (0h,1862,6)
__#3A37h 〜 __#D236h : ".journal" (0h,1862,7)
__#D237h 〜 __#E036h : エクステントファイル
__#E037h 〜 _#20636h : アトリビュートファイル
_#20637h 〜 _#D8236h : 未使用 （オールゼロ）
_#D8237h 〜 _#EA836h : カタログファイル (1Bh,70,7)
_#EA837h 〜 #1C7FFFh : 未使用 （オールゼロ）
#1C8000h 〜 #1C8000h : "VolumeConfig.plist" (39h,0,0)
#1C8001h 〜 #1C8103h : 未使用 （ゴミあり）
#1C8104h 〜 #1FFFFFh : 使用中 (39h,32,4)
ボリュームヘッダーにエクステントの情報が格納されている５つの特殊なファイルのうち、スタートアップファイルは、このＨＤＤには作成されていませんでした。あと、".journal_info_block" のアロケーションブロック番号もボリュームヘッダーに格納されていて、".journal_info_block" と ".journal" の２ファイルもファイルシステム上、特殊なファイルと言えるのかも知れません。
あまり意味はありませんが、図も作成してみました。40h * 4096 * 8 = 2097152 なので、１ビットを１ポイントで描画できます（...識別できないけど）。横 2048 縦 1024 です。0h 〜 4h で 4 * 4096 * 8 = 1024 * 128 = 131072 ビットになります。大きな図は i729534 です。
横軸の 0h 〜 40h はアロケーションファイルのブロック番号です。例えばカタログファイルの #D8237h の場合、対応するブロック番号は D8237h = (1Bh*4096+70)*8+7 なので、1Bh です（...D8237h を３つ組の数で (001Bh,70,7) と表現することもありますね）。
青色と灰色は Fig.F1 と同じで未使用と使用中のブロックですが、使用中のブロックのうち、アロケーションファイル等の特殊なファイルについては赤や橙などの色を付けました。
アトリビュートファイルとカタログファイルの後ろに未使用のエリアがあるのは、将来、この２つのファイルのサイズが増加した場合の為に空けてあるのでしょうか。１つのエクステントであるとそれなりにメリットがあり、他の一般のファイルのように、安易に分断してはいけないのかも。
＊＊＊
私「アロケーションファイルは、アロケーションブロックの #1h 〜 #3A35h にあります」
友「はい」
私「アロケーションファイルのブロック番号は、先頭を 0h として、0h 〜 3A34h とします。私が決めました」
友「え、まあ、そうですね」
私「アロケーションファイルのブロック番号で表現すると、アロケーションファイルは 0h にありますね」
友「...え？」
私「アロケーションファイルのブロック番号 0h とは、アロケーションブロックの #0 〜 #7FFFh の範囲だから」
友「ああ、そうね」
＊＊＊
