053 調査結果は封印されました（続き）
●053 調査結果は封印されました（続き）
友「この話は [052] の続きです。ここからは“私”に代わって私が続きを述べます」
＊＊＊
12/11 のファイル削除は、６時５９分８秒に開始、６時５９分２８秒で終了と読むのが正確だろう。すると、処理時間は 20 秒程だ。長くはない。多分ショックで記憶がイカれているんだろう。
（削除の操作を行ったのは、６時５８分１３秒もしくは６時５８分４４秒かも知れない。後日、再確認して必要なら訂正します）
まず、ジャーナルファイルからカタログファイルのデータを取り出す。アロケーションブロック番号が #D8237h 〜 #EA836h の範囲であれば、カタログファイルだ。カタログファイルも [030] でスクリプトを作成しているので、呼び出すだけでよい。リーフノードのレコードにはファイル名やエクステント情報があるんでしたね。
順次出力する。結果、不要なファイル（...DS_Store とか）は除外して、7092 個のファイル名が見つかった。エクステント情報付きだ。例えば、"lzss.py" は (218015385, 1) だ。これはアロケーションファイルでは 19FDh のブロックにある。
x = read_allocation(218015385, 1)
print x
すると、
/**************************************************************
LZSS.C -- A Data Compression Program
***************************************************************
4/6/1989 Haruhiko Okumura
Use, distribute, and modify this program freely.
Please send me your improved versions.
(以下、略)
表示された。小さなファイルばかりだが他にも数個試した。OK だ。
M0c で（ジャーナル機能オンで）HFS Plusを使用していて、うっかりファイルを削除してしまった場合には、直ちにＨＤＤを外して他のＯＳでジャーナルファイルを調べれば、失われたファイルを取り戻せる可能性が導けた（...あ、暗号化しているとダメだよ、多分ね）。
＊＊＊
友「海岸に無数にある砂粒の中から、ただのひと粒を拾い上げることは、どの砂粒なのか位置が正確に分かっているなら、簡単なことだ」
私「Zzzz（...真顔でいうこと？ ピンセットとかルーペが必要でしょうし、それに、近づいたときの勢いで、そのひと粒は行方不明にならない？）」
＊＊＊
続いて、エクステント情報の分布を調べよう。ファイル名は 7000 個程が出力されたが、失われたファイルのうち、どの位をカバーしているのかは未知だ。[051] の Fig.F1 と同様な図を作ればよい。エクステント情報をアロケーションブロック番号に変換して、横 1024 縦 512、１ポイントで 512 ビット分として作図したのが次の Fig.J2 だ（...これは大きな図 i730574 で見て欲しい）。
灰色や緑色、橙色はエクステント情報でカバーされているポイント、青色はカバーされていないポイントだ。橙色はカタログファイルのエクステント情報で、緑色はエクステントオーバーフローファイルの情報だ。
1602h 〜 1D1Eh の範囲は、だいだいカバーされている。ただし、１ポイントが 512 ビットなので、１ビットしかない可能性がある。アロケーションファイルと同様なビットマップを作成して、抜けの有無を調べないと。
より正確な分析は今後の課題だけども、単純にアロケーションブロック番号のユニークな個数をカウントすると、242,294,710 個あった。#0h 〜 #1D1Eh の範囲の 99.198 ％を占める。いい感じだ。
＊＊＊
＊＊＊
＊＊＊
さて。
ここから先は、仮説を含む現段階でのファイル復活の可能性の話です（...あとで書き換えるかもね）。
ファイル復活のために大切なことは、ファイルを削除してしまったら躊躇なくＨＤＤを外すことだ。内蔵ＨＤＤなら電源を落とすのです。普通に急いでシャットダウンです。
ＨＤＤを外したら、M0c に接続しては行けません。接続したら直ちにＯＳがファイルシステムの更新を始めます。
それから、ファイル復活の作業を始める前に可能ならば、同サイズの空きＨＤＤを用意してｄｄコマンド等でコピーしましょう。これは作業中に誤ってＨＤＤを壊してしまう可能性を考慮した保険です（...私は HFSP に未対応な古い Lin でコピーＨＤＤを作りました）。
ああ、これらの前提としてジャーナルファイルはオンにしておくこと。負荷が増えるそうですが、それ程には重くないらしいです。その分のメリットはあると思います（...個人的な経験からの話ですけれどね）。
急いで外す理由、それと M0c に再接続してはイケナイ理由は、ＯＳは（ファイル削除後の）空き時間でカタログファイルの整理を行うため、ノードがゼロクリアされることと、新規ファイル（".DS_Store" や spotlight 関係のファイル）を自動的に作成して、削除ファイルのアロケーションブロックが上書きされる（...可能性がある）こと、です。
これらの更新でジャーナルファイルの情報の上書きも進行します。
ＨＤＤをそのまま使用していると、やがてはアロケーションブロックやジャーナルファイルの情報は上書きされてしまいます。
カタログファイルはノードのサイズが 2 ブロック（8192 バイト）であるため、カタログファイルの更新時には、最低でも 2 回の書込みが必要だから、常にジャーナルファイルにデータが保管されると考えられます。もし、この仮説が正しければ、ジャーナルファイルのデータを再生するとことで、過去のカタログファイルを再現できることになります。
ただし、再現できるのは更新があったノードだけです。ファイル削除前のノードが得られるかがポイントです（ファイル削除時の保管データではなくて、その 1 つ前のデータが必要です）。残念なことに、これが必ず得られる保証はありません。ファイル削除前のノードが得られるかを確認するには、アロケーションファイルの分析が必要でした。
ファイル削除前のノードが得られたら、アロケーションブロックが上書きされていなければ、ファイル復活できそうです。
アロケーションブロックの上書きの有無は、ジャーナルファイルの分析である程度は判明すると考えられます。アロケーションファイルのビットマップのオンオフや、カタログファイルのエクステント情報の更新は、ボリュームヘッダの空き容量の増減と（...少くとも確認できた範囲では）一致しているからです。空きブロックが使用開始される、つまり上書きが発生するときには、ボリュームヘッダを始め、複数のファイルが更新されて、ジャーナルファイルに記録が残るという仮説ですね（...ジャーナルファイルの状態によっては確認できない場合もありますが、その場合には確認できない状態だと分かるはず）。
とは言え、ファイル復活した後の正当性のチェックは課題ですね。全ファイルのハッシュ値を保存する等の対策が考えられますけれども、事後的には無理。
現段階では分析が不十分で注意が必要なのは、断片化によりエクステントが 8 個より多くなった場合です。9 個目以降のエクステント情報は、エクステントオーバーフローファイルに書き込まれます。
ジャーナルファイルには、エクステントオーバーフローファイルのデータも保管されていますが、エクステントオーバーフローファイルのノードは 1 ブロック（4096 バイト）のため 1 回の書込みでよくて、ジャーナルファイルに更新時の全てのデータが保管される保証はありません。でも、エクステントオーバーフローファイルに変更があれば、カタログファイルも更新されるのでジャーナルファイルに記録されるかも知れません。例外の有無は未知です。現時点の分析では不足のデータは見つかっていませんけれど。更に正確な分析が必要です。
カタログファイルのノードが得られない場合、削除ファイルが少量ならば、アロケーションファイルの保管データから削除ファイルのアロケーションブロック番号を探すことも可能かも知れません。アロケーションファイルの更新が 1 ブロックだけなら、4096*8 = 32768 個に絞り込めます。この保管データは削除時のデータでよいので、ジャーナルファイルに残っていると期待できます。削除したファイルが断片化していた場合や ".DS_Store" という隠しファイルなどの更新などがあると、アロケーションファイルの更新も複数個になり、32768 個は N 倍に増えるでしょう。それでも根気良く探せば見つかるかも知れません。
削除時の 1 つ前のデータが残っていたら差分を調べることで、削除によってオフになったビットを特定できるでしょう。
ZIP ファイルや JPEG ファイルのようなファイル書式があるファイルなら、スクリプトを書いて探索することも可能でしょう。
".DS_Store" などのファイルも書式があるので探索対象から除外できますし、現存ファイルならビットがオン（使用中）となっていて探索の対象外ですね。
ファイルのデータは、エクステントとして、アロケーションブロックに保存されているとは限らないことに注意して下さい。ＨＤＤ上に保存されていることには違いはないのですけれども、カタログファイルのデータフォークにあるエクステント情報を元にファイルの復活を行うと、復活できないファイルが発生する可能性があります。
経験した範囲では、カタログファイルのリソースフォークにデータが保存されている場合と、アトリビュートファイルのレコードに保存されている場合がありました。
この他に復活できないファイルがあるかないか、確証を得ることは恐らく不可能です。祈りましょう。
あとは日頃の心掛けの話です。
ファイルが断片化していなければ、カタログファイルがなくてもファイル復活できる可能性が高まります。ZIP ファイルとかね。なので断片化はできるかぎり回避できるとよいです。
大きなファイルを複数個、同時にコピーする等すれば、たちまちにエクステントは 8 個を超えます。断片化を避けるため、ファイルの整理を行う時は順番に１つ毎にコピーを行うと良いです。面倒なときはｃｐコマンドか、スクリプトを書いて行えばよいです（...あるいはデフラグを行うのかな？）。
ファイルのコピー中に ".DS_Store" という隠しファイルが作成されると断片化の原因になる可能性があります。「ファインダ」というアプリが開いていたら、コピーを始める前に、閉じるか強制終了しましょう。そうしていても、ディスクトップのアイコンをいじったりしたら、"~/Desktop/.DS_Store" は更新されてします。どうしたら被害を最小にできるか全く知見が足りません。
コピー先のドライブによっては、".DS_Store" ファイルの作成を抑止できる設定があるそうです。ネットワークドライブ用の設定と、ＵＳＢドライブ用の設定を見かけました。これらをオンにすることも考えてよいと思います。
それと、Spotlight 関係のファイル（".store.db" や "store.db" ですね）も断片化の原因になることがあります。これも設定で作成停止できるそうです。止めましょう。
時々、関連ファイル一式を ZIP ファイルにして置くのも良いと思います。
あと、外付けＨＤＤにファイルをコピーするとき、コピー終了後にＨＤＤを外すのは少し待つのが良いかも知れません（...不要かも知れませんが）。約 30 秒です。待つよりもアンマウントの操作を行ってから外すと確実ですね。
ジャーナルファイルを観察する限りでは、ファイルの書込みはメモリ上で操作されていて、ＨＤＤへの書込みは 30 秒間隔なように見えるからです。つまり、遅延書込をしているかも知れません。
遅延書込をしているなら、ファイル保存の直後に電源断が発生するとファイルが失われる可能性があるはずです。実際には M0c でそのようなトラブル事例があるのか、ググっても見つかりません。なので心配無いかも、杞憂かも知れません。
W1n の場合は「遅延書き込み, データ紛失」等でググると沢山の例が見つかります。一方で、W1n でもＵＳＢメモリや外付けＨＤＤは遅延書込は無効になったので（...W1n10 より前は有効だった？）いつ外しても大丈夫とか説明があり。...外付けなら、そうだよね。なので、優れたＯＳであるらしい M0c なら、やっぱり杞憂かもね。
多分、30 秒間隔なのはアロケーションファイルやカタログファイル等の更新だけなのでしょう。あははは。
＊＊＊
友「私からは以上です」
私「Zzzz（...あの頃はマウスを弄ってファイル整理するのが、何か楽しかったの、とても後悔してます）」
＊＊＊
