ＭＯ救出作戦


　最近、２件続けて読めなくなったＭＯ（光磁気ディスク）の修復に取り組む機会があり、ＭＯのファイルシステムについて、いくつか調べてわかったことをここにまとめておきます。なお、ＭＯの解析および修復にはshifuji氏制作のフリーソフト「ＭＯデバッガー」を利用させていただきました。便利なツールを開発された氏に感謝します。

1.ファイルシステム概要
　WindowsのファイルシステムはDOS時代のものを発展させ、進化してきました。ＭＯにおいても、基本的にはＦＡＴ（ファイルアロケーションテーブル）およびディレクトリ情報とでメディアの使用状況およびファイルの所在が管理されています。その概要をここに紹介します。例として、230MBＭＯをWin2000でフォーマットした直後、下図のように１つのサブディレクトリおよび２つのファイルがルートディレクトリに記録されたものを取り上げます。



　ディスクのアドレッシングはよく、シリンダ番号、ヘッド番号、セクタ番号の組み合わせで表記されますが、ＭＯをはじめとするSCSIディスクではLBA（論理ブロック番号：Logical Block Address）と呼ばれる通し番号でアドレッシングされます。230MBのＭＯでは論理ブロックは512バイトで、試験的に作成したＭＯでは、各ブロックは下表のように使われれていました。

LBA(16進数)ブロック数内容（クリックでダンプ表示）補足
00001IPLブートローダ
0001〜00DA218FATブロック使用状況
00DB〜01B4218予備FAT（上記backup）
01B5〜01D432ルートディレクトリファイル名、サイズ、作成日など
01D5〜01DC8ファイル本体program.htm
01DD〜01E48サブディレクトリtest
01E5〜0294176ファイル本体test内のgazou.jpg
0295〜029C8ファイル本体制御pro.asm


　ちなみに、これまで調べたＭＯの中には、ルートディレクトリがLBA=1B1、または1B3から始まるものがあり、LBA=0のブロックにかかれるコードで異なってくるようです。フォーマット済みの新品230MB-MOをそのまま使った時は、1B3からルートディレクトリ情報が書き込まれていました。

２．ＦＡＴ
　FATは８ブロック単位（512×8=4096バイト）を１クラスタとし、各クラスタの使用状況を順に２バイトのコードで示します。

　図の最初のコードFFF8（ＭＯ上の記録は86系おなじみのローバイト、ハイバイトの順）は先頭ブロックのサイン。以下は第１クラスタ（ルートディレクトリのエリア）、第２クラスタ（上記program.htmの記録エリア）、第３クラスタと順に使用状況、すなわち、FFFFは終了クラスタ（そのクラスタでファイルが完結していることを意味します）、それ以外は継続するクラスタの番号を示しています。 たとえば、コード0005はそのクラスタのファイルの続きが第５クラスタにあることを示し、第４クラスタから始まるファイルが0005,0006,…,0019クラスタまで続くことがわかります。なお、0000は未使用領域であることを示します。
　　
３．ルートディレクトリ
　ルートディレクトリにはファイル名、ファイルの種類、作成年月日・時分やファイルの所在場所（先頭クラスタ番号）、サイズなどが記録されています。左図はその主な様子を示します。

　ファイルprogram.htmについてみると、種類はコード20（通常の読み書き可能なファイルを示す）、先頭クラスタ番号が0002、ファイルサイズが(00000BEF)16=3055バイトであることがわかります。２つ目のtestについては、種類が10（サブディレクトリを意味します）、先頭クラスタが0003、ファイルサイズはディレクトリなので０になっています。３つ目は「制御pro.asm」のようにファイル名に全角文字を含む場合で、ディレクトリ情報エリアを倍取り、長いファイル名が記録できるようになっています。
　
４．ファイル本体
　ファイルprogram.htmの冒頭部分です。ルートディレクトリでこのファイルが0002クラスタに記録されていることがわかりましたが、LBAは01C5+（クラスタ番号）×8で計算でき、01d5からファイルが記録されていることが推測できました。HTMLのテキストファイルなので、右のASCII欄でファイルの様子が確認できます。　
　
５．サブディレクトリ
　サブディレクトリtestの様子です。本ディレクトリおよび親ディレクトリの所在およびファイルgazou.jpgの情報が書かれています。

ちなみに、
　　・本ディレクトリ（.）の先頭クラスタ…0003
　　・親ディレクトリ（..）の先頭クラスタ…0000
　　・ファイルgazou.jpgの先頭クラスタ…0004
となっています。

６．ＭＯ救出事例
　　ＭＯデバッガーを起動すると、右図のようなウィンドウが表示されます。LBA欄に数値を入れ、「Read」をクリックするとその内容が表示されます。また、「Write」をクリックすると内容を書き換えることができます。ＭＯが読めなくなったといっても全てのブロックが壊れているわけではないので、壊れたブロックを見つけ、それを修復すればよいのです。今回は、たまたま２種類のブロックの破壊に遭遇しましたが、その対処の様子を簡単に記しておきます。

  1. FATの一部が読めない（エラーが出る）
    FATを順に読んでいくと、あるLBAのブロックより２つ続けてREADエラーが出ました。予備FATの該当ブロックを読み出し、エラーのあったブロックのLBAを指定して書き込む（要するに、予備FATからコピーする）ことで解決、のはずでしたが、なぜかルートディレクトリブロックの一部が別のものに書き変わっており、やむなく手探りでリンク可能なサブディレクトリのブロックを探し、エントリ値を計算してルートディレクトリを作成、書き込むことで、なんとか大半のファイルを読み出すことが可能になりました。


  2. IPLが読めない（エラーが出る）
    ルートディレクトリが同じLBAから始まる他のＭＯからIPLを読み出し、それを書き込むことで解決。これは、意外にあっけなく終わりました。


　今回のＭＯ救出作戦はまさに試行錯誤の連続でした。ＭＯのファイルシステムはＦＤと同じだろうということから、かってＦＤの救出を試みた経験をふまえて取り組み始めましたが、まずはそのファイルシステム構成の把握に多くの時間を要しました。また、予想もしないアクシデントに見舞われ、修復に手間取ってしまいました。どうもＭＯデバッガーでの書き込みによって、時々勝手に他のブロックが書き変わることがあるようです。なんとか対応はしたもののもう一度同じことができるかどうか、いささか自信がありません。人から修復の依頼を受けても「だめもとでよければ」としか言えない現状です。あくまでもＭＯ救出の参考ということで、このページを活用いただければ幸いです。

ホームへ