■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.
グリーンネット・トップページへ戻る
一覧に戻る
Linux Ext2fs Undeletion mini-HOWTO
Aaron Crane
aaronc@pobox.com
JF Project - 日本語訳
JF@linux.or.jp
v1.3, 2 February 1999
次のような状況を想像してほしい。ここ 3 日間、飲まず食わすでシャワーも浴
びずに作業を続け、ようやくその抑えきれないハッキングの衝動が実を結んだ
。ついに、プログラムが完成したのだ。世界的な賞賛と名声をもたらすだろう
ほどの。あとは tar でかためて、Metalab にあげるだけだ。おっと、Emacs の
バックアップファイルの削除を忘れていた。ここであなたは、rm * ~ とコマン
ドを打つ。そして、嗚呼、コマンドに余計なスペースを入れてしまったことに
気付くのである。世紀の逸品を削除してしまった！しかし、万策尽きたわけで
はない。この文書は、Ext2 ファイルシステム上で削除してしまったファイルを
復旧する方法について解説している。おそらく、最後にあなたはそのプログラ
ムをリリースできるはず....
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents
1. はじめに
1.1. 更新歴
1.2. この文書の正式な公開場所
2. ファイルを誤って削除しないためには
3. どの程度の復旧率が見込めるのか？
4. では、どうやって復旧するのか？
5. ファイルシステムのマウント解除
6. i-node を直接書き換える場合の準備
7. 別の場所にデータを書き出す場合の準備
8. 削除した i-node を見つけだす
9. i-node の詳細を調べる
10. データブロックの復旧
10.1. 小さなファイル
10.2. 大きなファイル
11. i-node を直接いじる
12. 将来的にはもっと簡単になるでしょうか？
13. 一連のプロセスを自動化するツールはないですか？
14. あとがき
15. Credit と参考文献
16. 法的な事柄
17. 日本語訳について
1. はじめに
この mini-Howto は、ext2 ファイルシステム上で削除してしまったファイルを
復旧する方法について、そのヒントを提供しようとするものです。また、そも
そもファイルを誤って削除しないようにするための予防策についても、若干説
明しています。
もちろん、たった今 rm コマンドで「ちょっとした事故」を起こしてしまった
人のために、この文書は役に立つでしょう。とはいえ、いずれにしても多くの
読者に本文書を読んでもらいたいとも願っています。いまはまだわからないで
しょうが、ある日この情報があなたの窮地を救うかもしれないのですから。
この文書は、読者が UNIX ファイルシステム全般についてある程度知っている
ことを前提にしていますが、普段 Linux 使っている人ならたいてい意味が分か
るようにもしたつもりです。もし読者が全くの初心者なら、Linux 上でのファ
イルの復旧には、さしあたりかなりの技術的知識と忍耐とが要求されていると
いうことを述べておきます。(訳注：The Linux Kernel に比較的詳しい解説
があります。)
ext2 ファイルシステム上での削除ファイルの復旧には、少なくともそのファイ
ルが保存されていた生(raw)デバイスに対する読み出しアクセスが不可欠です。
一般にこのことは root での作業を意味しますが、(Debian GNU/Linux などの) ディストリビューションのなかには、disk グルー
プに所属しているメンバーなら、そうしたデバイスにアクセスできるようにな
っているものもあります。 e2fsprogs パッケージにある debugfs も必要にな
りますが、このユーティリティはお使いのディストリビューションに含まれて
いると思います。
著者がこの文書を書いたのは、rm -r というなんとも愚かで破壊的なコマンド
を root で使ってしまったという個人的な経験に由来しています。97 個の
JPEG ファイルを削除してしまったのです。これらは是非とも必要で、かつ他か
ら再び取得するのはほとんど不可能な代物でした。しかし、(Section 15 の章
にある) tips を使ってかなり粘った結果、91 枚を無傷で復旧できました。残
りの画像についても、 5 枚まではなんとか取り戻すことができました (各々が
どういう画像か分かる程度の復旧でした)。最後の一枚だけは表示不能でしたが
、これについても情報欠落を 1024 バイト以下程度にはできたと思っています
(しかし不運にも欠落した情報はファイルの先頭部分だったのです。 JFIF ファ
イル形式については何も知らなかった当時としては、出来るだけのことはやっ
たのですが)。
削除ファイルの復旧率として、どの程度の値を期待できるかについてはのちほ
ど議論するつもりです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.1. 更新歴
この文書の公式リリースとそのリリース日は、以下のとおりです。
・ v1.0, 1997年1月18日
・ v1.1, 1997年7月23日 (Section 1.1.1 参照)
・ v1.2, 1997年8月4日 (Section 1.1.2 参照)
・ v1.3, 1999年2月2日 (Section 1.1.3 参照)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.1.1. バージョン 1.1 での変更点
バージョン 1.1 での変更点は、なによりも、ファイル復旧の例題にあった著者
の思い違いを訂正したことです。誤りを指摘してくれたすべての方に感謝しま
す。プログラムの相互作用について書く際には、もっと慎重になろうと思いま
す。
二つ目は、UNIX ファイルシステムのレイアウトの説明を書き直したことです。
これによって、おそらくより分かり易くなったと思います。もともと自分でも
満足してはいなかったのと、複数の方からのコメントでも不明瞭との指摘をい
ただいていたからです。
三つ目は、文書の中程に uuencode した fsgrab の gzip tarball があったの
を削除したことです。このプログラムは、現在著者のウェブサイト や Metalab (およびそのミラーサイト)から入手
できます。
四つ目は、この文書が Linux Documentation Project の SGML Tools に合わせ
て SGML 化されたことです。このマークアップ言語は、スクリーン表示や印刷
の便宜に応じて、(HTML や LaTeX などの)他の複数のマークアップ言語へも簡
単に変換できます。この利点のひとつは、印刷時の美しい版組がより簡単に実
現できるということです。またウェブ上で閲覧する場合にはクロスリファレン
スやハイパーリンクが使えます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.1.2. バージョン 1.2 での変更点
この改訂は、おもに項目の追加のためです。主として、読者からの提案による
変更であり、そのひとつは特に重要なものです。
第一の変更箇所は、Egil Kvalegerg からの提案です。
彼は、debugfs の dump コマンドを指摘してくれました。Egil、どうもありが
とう。
第二の変更箇所は、重要なファイルを削除してしまわないために chattr コマ
ンドを使うということを指摘した点です。 Herman Suijs
からの指摘です。
文書の abstract が改訂されました。いくつかの組織とソフトウェアに関する
URL も追加しました。(typo の訂正を含む)各種マイナーな変更もありました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.1.3. バージョン 1.3 での変更点
最初のリリースから 17 カ月経ちましたが、新しい追加事項はほとんどありま
せん。今回は、小さな間違いをいくつか修正しただけです(typo やリンク切れ
等、-- 特に、Open Group へのリンクがなかったことの修正など)。そして、カ
ーネルバージョンや lde のバージョンなどあまりにも古くなった記述を一部更
新しました。それと、"Sunsite" を "Metalab" に変更しました。
このリリースは、バージョン 2.0 になる前の最後のリリースだと考えています
。2.0 は、完全な HOWTO 文書になるはずです。メジャーバージョン番号の繰り
上げにふさわしい充分な解説を加えられるよう、目下作業中です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.2. この文書の正式な公開場所
この文書の最新の公開バージョンは、必ず次の場所(およびそのミラーサイト)
に掲載する予定です。
Linux Documentation Project
また、最新版は、著者のウェブサイト にも各種
フォーマットで掲載されています。
・ SGML ソース 。こ
れは、著者が SGML Tools パッケージを使って書いたこの文書のソースフ
ァイルです。
・ HTML 。これは、SGML
ソースから自動的に生成される HTML バージョンです。
・ Plain text 。これ
も、SGML ソースから自動的に生成されるテキストバージョンです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. ファイルを誤って削除しないためには
ファイルの復旧という点に関して、Linux は MS-DOS とは勝手が違うというこ
とをまず肝に銘じてください。MS-DOS (およびその悪魔の子である Windows
95) の場合、一般にファイルの復旧はかなり簡単です。復旧処理を自動で行う
ユーティリティが、オペレーティングシステム (まあ、著者はこの用語を広義
の意味で使うわけですが) に付属しているからです。しかし、Linux の場合、
そうはいきません。
従って、ルール No.1 (そう言いたければ「聖なる誓い」) は
鉄則: バックアップを取るべし
すなわち、何であれ、バックアップを取るようにすること。すべてのデータが
対象です。著者同様、読者のコンピュータにはメールその他の交信記録やプロ
グラム、各種文書など、長年に渡る情報が大量に蓄積されているはずです。も
しも突発的なディスク障害が起こったり、あるいは(縁起でもないですが)悪意
を持ったクラッカーにディスクの内容を消去されてしまったりした場合、日常
生活がどれほど混乱するかを考えてみてください。決してあり得ないことでは
ありません。現に、著者はまさにそうした状況に陥った多くの人たちとメール
のやり取りをしてきました。賢明な Linux ユーザは、今すぐ適当なバックアッ
プデバイスを買ってきて、適切なバックアップスケジュールを立てた上で、そ
れを厳守するようおすすめします。著者自身は、サブマシン上の余ったディス
クを使って、イーサネット経由でホームディレクトリを定期的にミラーするよ
うにしています。バックアップスケジュールの立て方に関する詳細は、Frish
(1995) をご覧下さい ( Section 15 参照)。
では、バックアップをしていない場合は、どうすべきでしょうか？ (あるいは
バックアップがあったとしても。重要なデータについては、幾重もの安全対策
をとることは悪い考えではありません)
重要なファイルのパーミッションは 440 (あるいはそれより厳しい値) にしま
しょう。書き込みをできなくすれば、 rm コマンドで削除する前に、削除をす
るか否かの確認メッセージが表示されるようになります。(ただ、著者の場合、
それでも rm -r コマンドでディレクトリ内を再帰的に削除する際には、最初の
確認表示の段階でプログラムを停止させて、rm -rf コマンドを打ってしまった
りします。)
特別なファイルに関しては、隠しディレクトリにハードリンクを作成するのも
よい方法です。これは、あるシステム管理者から聞いた話ですが、彼は /etc/
passwd ファイルを何度か誤って削除したことがあったそうです (これはシステ
ムにほぼ破壊的なダメージを与えます)。それに対する対処方法のひとつは、以
下のようなものだったそうです (これは root で実行します)。
┌──────────────────────────────────┐
│ # mkdir /.backup │
│ # ln /etc/passwd /.backup │
└──────────────────────────────────┘
こうしておくと、ファイルの内容を完全に消去するのがかなり面倒になります
。もし次のようなコマンドを実行したとしても、
┌──────────────────────────────────┐
│ # rm /etc/passwd │
└──────────────────────────────────┘
その際には、
┌──────────────────────────────────┐
│ # ln /.backup/passwd /etc │
└──────────────────────────────────┘
とすれば、ファイルを復旧できます。もちろん、ファイルを上書きしてしまう
とこの方法は役に立たないので、いずれにしてもバックアップは必要です。
ext2 ファイルシステム上では、ext2 の属性を利用してファイルやディレクト
リを保護することができます。この属性の操作には chattr コマンドを使いま
す。属性にはまず、「追加のみ可能(append-only)」属性というのがあります。
この属性が付いたファイルは、内容の追加は可能ですが、削除が出来なくなり
、既存の内容を上書きすることもできなくなります。ディレクトリにこの属性
が付いている場合は、そのディレクトリ内のファイルやサブディレクトリは、
通常通り変更は可能ですが、ファイルの削除が出来なくなります。「追加のみ
可能」属性は、次のように設定します。
┌──────────────────────────────────┐
│ $ chattr +a ファイル名 │
└──────────────────────────────────┘
また、「変更不可(immutable)」属性というのもあり、これは root 権限でのみ
設定や解除ができるようになっています。この属性が付いたファイルやディレ
クトリは、変更、削除、名前の変更、(ハード)リンクの作成が不可能になりま
す。設定は、次のようにします。
┌──────────────────────────────────┐
│ # chattr +i ファイル名 │
└──────────────────────────────────┘
ext2fs には、さらに「削除不可(undeletable)」という属性もあります (
chattr に +u を付けて設定します)。意味するところは、この属性を付けたフ
ァイルが削除された場合、実際に再利用されるかどうかに関わらず、一旦安全
な場所に移動され、一定期間経過後に削除されるというものです。ただ残念な
ことに、この機能はメインストリームのカーネルにはまだ実装されていません
。過去に実装されかけたことはあったのですが、(著者の知る限り) 現在のカー
ネルではまだ利用可能とはなっていません。
rm は rm -i へのエイリアスとするか、同機能の関数に置き換えるべきだ、と
主張する人もいます (rm -i は、ファイル削除の際に必ず確認を求めます)。実
際に Red Hat は、root を含む全ユーザに対してこ
の機能をデフォルトで設定しています。しかし、著者の個人的な意見では、ソ
フトウェアは命令通り忠実に動くべきだと思っているので、こうした見解には
賛同できません。これには問題もあります。遅かれ早かれ、ユーザはシングル
・ユーザモードで起動したり、別のシェルを使ったり、異なるマシンを利用し
たりするはずですが、そうした場合にはこの rm 機能は無効になります。削除
確認の表示が出ることに慣れきっていると、自分が置かれた状況を考えずに、
一度に多数のファイルを削除指定してしまわないとも限りません。同様に、rm
コマンドを各種スクリプトやプログラムで置き換えるのも、著者の考えでは、
危険なことだと思います。
もう少しましな方法としては、rm とは別のコマンド名で、「ゴミ箱」形式の削
除ができるようなパッケージを使ってみることです。詳しくは、Peek, et al
(1993) (Section 15 参照) を見てください。ただ、これにも問題はあります。
このパッケージの作者は、削除についてユーザが無頓着になるよう奨励してい
るように思われるからです。Unix システム上では、むしろ、自己責任に基づく
慎重な運用というアプローチが基本になるはずです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. どの程度の復旧率が見込めるのか？
場合によります。Linux のような高機能、マルチユーザ、マルチタスクのオペ
レーティングシステムでファイルを復旧する場合の問題点のひとつは、誰がい
つディスクに書き込みをするか分からないということです。ファイルを削除す
るよう命令されると、オペレーティングシステムはそのファイルが占めていた
ディスクブロックを、新規ファイルに割り当てるための空間として認識します
。(これは、Unix 系オペレーティングシステムに見られる一般原則の典型的な
例です。つまり、カーネルやその関連ツールは、ユーザが仕組みを理解した上
で作業していることを前提にしているということです。) 一般に、マシンを酷
使しているほど、ファイルの復旧は難しくなります。
また、ディスクのフラグメンテーションもファイルの復旧率に影響します。削
除ファイルがフラグメンテーションの激しいパーティションにあった場合には
、そのファイル全体を復旧できる確率は低下します。
もし読者のマシンが (著者のマシンのように) 事実上シングルユーザのワーク
ステーションであり、ファイルを削除してしまった瞬間にディスクを酷使する
ような処理が行われていなかったとするなら、冒頭で紹介した著者の場合と同
等の復旧率を達成できると思われます。著者はファイルの 94 % 近くを無傷で
復旧しました (しかもこれらはバイナリです)。おそらく 80 % 以上復旧できれ
ば、かなり満足できるはずだと思います。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. では、どうやって復旧するのか？
復旧作業の主要な部分は、raw パーティションデバイスからデータを見つけだ
して、 +それをオペレーティングシステムが認識できるようにすることです。
+これには基本的に二種類の方法があります。ひとつは、現在のファイルシステ
ム上にある削除されたファイルの i ノードをいじって 'deleted' フラグを取
り除き、データが魔法のようにもとの場所に戻ってくるように祈る、というも
のです。もうひとつの、より安全ではありますが時間のかかる方法は、パーテ
ィション内にあるデータを探し出して、別のファイルシステム上の新規ファイ
ルにそのデータを書き出すというものです。
ただし、データ復旧に取りかかる前に、やっておくべき作業が何段階かありま
す。詳細は、Section 5, Section 6 および Section 7 をご覧ください。実際
にファイルを復旧する方法は、 Section 8, Section 9, Section 10, Section
11 を参照してください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. ファイルシステムのマウント解除
どちらの方法を使うにせよ、まず最初に削除したファイルが入っているファイ
ルシステムのマウントを解除する必要があります。ここで慌てると、ファイル
システムをめちゃめちゃにしてしまう可能性があるので注意してください。こ
の作業は、ファイルを削除してしまったことに気が付いた時点で出来る限りす
ばやく行わなければなりません。マウント解除が早ければ早いほど、データが
上書きされる可能性も少なくなります。
最も簡単な方法は、次のようなものです。ここでは、削除したファイルが /usr
にあるものと仮定しています。
┌──────────────────────────────────┐
│ # umount /usr │
└──────────────────────────────────┘
しかし、/usr 以下に置かれているものが使えなくなるのは困るかもしれません
。その場合、read-only で再マウントします。
┌──────────────────────────────────┐
│ # mount -o ro,remount /usr │
└──────────────────────────────────┘
削除したファイルがルートパーティション上にある場合は、-n オプションを付
けて、/etc/mtab ファイルへの書き込みを避ける必要があります。
┌──────────────────────────────────┐
│ # mount -n -o ro,remount / │
└──────────────────────────────────┘
どの方法でマウント解除するかに関わりなく、他のプロセスが当該のファイル
システムを使っている可能性もあります (その場合、マウント解除は失敗し、
"Resource busy" のエラーが表示されます)。こういう時のために、特定のファ
イルやマウントポイントを使っているプロセスに対してシグナルを送るプログ
ラムが存在します。fuser です。これを /usr パーティションに対して使って
みましょう。
┌──────────────────────────────────┐
│ # fuser -v -m /usr │
└──────────────────────────────────┘
上記コマンドによって、対象となるプロセスが列記されます。重要なプロセス
が存在しないことが確認できたら、次のコマンドを実行します。
┌──────────────────────────────────┐
│ # fuser -k -v -m /usr │
└──────────────────────────────────┘
こうすると個々のプロセスに SIGKILL シグナルを送ります (これはプロセスを
確実に殺すシグナルです)。あるいは、次のようにしても結構です。
┌──────────────────────────────────┐
│ # fuser -k -TERM -v -m /usr │
└──────────────────────────────────┘
これは個々のプロセスに SIGTERM シグナルを送ります (これはプロセスを正常
に終了させるシグナルです)。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. i-node を直接書き換える場合の準備
著者としては、この方法はおすすめしません。これはファイルシステムの低レ
ベル層をいじるわけですが、そういうやり方が賢明だとは思えないからです。
またこの方法では、確実に復旧できるのは個々のファイルの最初の 12 ブロッ
クだけなのです。したがって、大きなファイルを復旧する際は、通常、最終的
に他の方法を使わざるを得ません。(とはいえ、詳しい情報は、 Section 12 を
ご覧ください。)
どうしてもこの方法を使わないと気が済まない場合は、 raw パーティションの
データを他のパーティション上にディスクイメージとしてコピーし、そのイメ
ージを loopback を使ってマウントすることをおすすめします。
┌──────────────────────────────────┐
│ # cp /dev/hda5 /root/working │
│ # mount -t ext2 -o loop /root/working /mnt │
└──────────────────────────────────┘
(注意してほしいのは、mount コマンドのバージョンが古いと、上記のコマンド
で問題が生じるかもしれないということです。 mount が上手く動かない場合、
最新バージョンか、少なくとも version 2.7 以上に更新することを強くおすす
めします。古いバージョンには、致命的なセキュリティ上のバグがあるからで
す。)
このように loopback を使っておくと、そのファイルシステムを完全に破壊し
てしまった場合でも、 raw パーティションを再度コピーしてやり直すだけで済
みます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. 別の場所にデータを書き出す場合の準備
別の場所にデータを書き出す方法を取る場合は、まずレスキューパーティショ
ンがあるかどうかを確認する必要があります。つまり、復旧したいファイルの
コピーを書き出す場所を確保するわけです。おそらく、読者のシステムには複
数のパーティションがあり、ルートや /usr、/home は別々のパーティションに
分かれていると思います。このうちのひとつを使っても、全く問題ないはずで
す。どれかひとつのパーティション上に、新規のディレクトリを作成しましょ
う。
ルートパーティションしかなくて、すべてをそこに保存している場合は、若干
面倒です。それでも MS-DOS や Windows のパーティションが使えたり、もしく
はカーネルモジュールとして ramdisk ドライバを使えるようにはなっているの
ではないでしょうか？ ramdisk を使うには (これは、1.3.48 以降のカーネル
であることが前提です) 次のようにします。
┌──────────────────────────────────┐
│ # dd if=/dev/zero of=/dev/ram0 bs=1k count=2048 │
│ # mke2fs -v -m 0 /dev/ram0 2048 │
│ # mount -t ext2 /dev/ram0 /mnt │
└──────────────────────────────────┘
これによって 2 MB の ramdisk 領域が作成され、/mnt 上にマウントされます
。
少々注意: 読者が kerneld (もしくは、 2.2.x や 2.1.x 以降のカーネルを使
っているならその後継である kmod) を使ってカーネルモジュールをロードして
いる場合、ramdisk 領域から不揮発性ストレージへのコピーが終了するまで
ramdisk のマウントを解除してはいけません。ramdisk 領域のマウントを解除
すると、kerneld はモジュールを (一定時間経過後に) アンロードできるもの
と思ってしまい、さらに実際にアンロードされてしまうと、ramdisk のメモリ
領域はカーネルの他の部分に再利用されてしまって、苦労してデータの復旧に
費やした時間が全く無駄になってしまうからです。
Zip や Jaz, LS-120 といったリムーバブル装置を持っているなら、レスキュー
パーティションの置き場所として是非利用してください。持っていない場合は
、フロッピーでいきましょう。
他に必要になるのは、パーティションデバイス上から必要なデータを読み出せ
るプログラムです。いざとなれば dd でも出来るのですが、でも例えば、パー
ティションの 600 MB 目から 800MB 目までの領域を読み出そうとするような場
合、dd は最初の 600 MB の領域を無視できず、どうしても頭から読み込もうと
してしまうのです。高速なディスクを使っている場合でも、これにはかなりの
時間が掛かります。この振る舞いをなんとかしようとして、著者は、パーティ
ションの途中にある領域を適切に読み出しできるプログラムを作成しました。
fsgrab という名前のプログラムです。このプログラムのソースパッケージは、
著者のウェブサイト や
Metalab (とそのミラーサ
イト) にあります。読者がこの方法を使ってくれるものと仮定して、ここから
先は、読者が fsgrab を持っているものとして説明します。
ただ、復旧しようとしているファイルの大きさがどれも 12 ディスクブロック
を超えない場合 (1 ディスクブロックは通常 1 Kb です)、fsgrab は不要です
。
fsgrab が必要だがダウンロードとビルドがイヤな場合は、 fsgrab のコマンド
ラインを dd のコマンドラインに置き換えて考えてください。例えば、fsgrab
のコマンドラインが以下のような場合、
┌──────────────────────────────────┐
│ fsgrab -c count -s skip device │
└──────────────────────────────────┘
これに相当する dd のコマンドラインは (おそらく処理時間が余分に掛かりま
すが) 次にようになります。
┌──────────────────────────────────┐
│ dd bs=1k if=device count=count skip=skip │
└──────────────────────────────────┘
ここで一応警告しておきます。fsgrab プログラムは、著者のもとでは完璧に機
能しましたが、読者のもとでどのような振る舞いをしようとも著者は一切責任
を負えません。実際これは、きちっと設計されたプログラムではなく、なんと
か処理をこなすだけものにすぎません。免責に関する詳細は、プログラム付属
の COPYRIGHT ファイルに記載された "No Warranty" の章をご覧ください (the
GNU General Public License です)。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. 削除した i-node を見つけだす
次に踏むべき手順は、ファイルシステムを走査して、どの i-node が最近解放
されたのかを調べることです。この作業を実行するには debugfs を使います。
debugfs にファイルシステムが保存されているデバイスのデバイスファイル名
を付けて起動してください。
┌──────────────────────────────────┐
│ # debugfs /dev/hda5 │
└──────────────────────────────────┘
i-node を直接変更したい場合は、-w オプションを付けてファイルシステムへ
の書き込みができるようにします。
┌──────────────────────────────────┐
│ # debugfs -w /dev/hda5 │
└──────────────────────────────────┘
削除した i-node を探すための debugfs のコマンドは lsdel です。プロンプ
トから次のように打ち込んでください。
┌──────────────────────────────────┐
│ debugfs: lsdel │
└──────────────────────────────────┘
ディスク装置へのアクセス音がしばらく続いた後で、長い i-node のリストが
パイプ処理され、($PAGER で設定した) ページャに表示されます。このリスト
を別の場所に保存したい場合、less を使っているなら、-o オプションの後に
出力ファイル名を指定します。 less 以外を使っているなら、出力を別の場所
に送る必要があります。次のようにしてください。
┌──────────────────────────────────┐
│ debugfs: quit │
│ # echo lsdel | debugfs /dev/hda5 > lsdel.out │
└──────────────────────────────────┘
ここで、削除日時、ファイルサイズ、ファイルタイプ、パーミッションの数値
、ファイル所有者などの情報だけに基づいて、復旧したいファイルがどれなの
かを見つけださなければなりません。運良く、五分ほど前に削除した大きなフ
ァイル等であれば、比較的簡単に見つけだすことができるでしょう。もしそう
でなければ、リストをしらみつぶしにあたっていきましょう。
可能なら、i-node のリストをプリントアウトすることをおすすめします。調べ
るのがずっと楽になります。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
9. i-node の詳細を調べる
debugfs には stat コマンドがあり、これを使うと i-node の詳細を表示する
ことができます。復旧リストにあるそれぞれの i-node に対して stat コマン
ドを実行してください。例えば、i-node 番号 148003 を調べようとする場合は
、次のようにします。
┌─────────────────────────────────────┐
│ debugfs: stat <148003> │
│ Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1 │
│ User: 503 Group: 100 Size: 6065 │
│ File ACL: 0 Directory ACL: 0 │
│ Links: 0 Blockcount: 12 │
│ Fragment: Address: 0 Number: 0 Size: 0 │
│ ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996 │
│ atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996 │
│ mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996 │
│ dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996 │
│ BLOCKS: │
│ 594810 594811 594814 594815 594816 594817 │
│ TOTAL: 6 │
└─────────────────────────────────────┘
復旧したいファイルがたくさんあるなら、上記の手続きを自動化したいとお思
いでしょう。lsdel で作成した復旧リストが lsdel.out ファイルに入っている
とするなら、まず次のようにします。
┌──────────────────────────────────┐
│ # cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes │
└──────────────────────────────────┘
これによって作成された inodes ファイルには、復旧すべき i-node の i-node
番号だけが一行にひとつずつ記述されています。この情報をファイルに保存し
たのは、その方が後々便利だからです。そして次に、以下のようにします。
┌──────────────────────────────────┐
│ # sed 's/^.*$/stat <\0>/' inodes | debugfs /dev/hda5 > stats │
└──────────────────────────────────┘
以上で stats ファイルに、stat コマンドの出力結果が全て記録されます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10. データブロックの復旧
ここでの手順は、復旧しようとするファイルの大きさが 12 ディスクブロック
以下であるか否かによって、非常に簡単にもなり、逆に面倒にもなり得ます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10.1. 小さなファイル
ファイルのサイズが 12 ブロック以下なら、ファイルのデータを保持している
ブロックナンバーのすべてが、検出した i-node の中に書き込まれています。
その i-node に対して stat を実行すると、ブロックナンバーを直接読み出す
ことができます。さらに debugfs には、この処理を自動化するコマンドも組み
込まれています。前章で取り上げた例をここでも使って説明します。
┌─────────────────────────────────────┐
│ debugfs: stat <148003> │
│ Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1 │
│ User: 503 Group: 100 Size: 6065 │
│ File ACL: 0 Directory ACL: 0 │
│ Links: 0 Blockcount: 12 │
│ Fragment: Address: 0 Number: 0 Size: 0 │
│ ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996 │
│ atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996 │
│ mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996 │
│ dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996 │
│ BLOCKS: │
│ 594810 594811 594814 594815 594816 594817 │
│ TOTAL: 6 │
└─────────────────────────────────────┘
上記ファイルは 6 つのブロックから成り立っています。12 ブロックという限
度以下なので、debugfs コマンドを使ってこのファイルを別の場所、ここでは
/mnt/recovered.000 に書き出すことができます。
┌──────────────────────────────────┐
│ debugfs: dump <148003> /mnt/recovered.000 │
└──────────────────────────────────┘
もちろん fsgrab コマンドでも同様の処理が可能です。 fsgrab の場合は、次
のようにします。
┌──────────────────────────────────┐
│ # fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000 │
│ # fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000 │
└──────────────────────────────────┘
debugfs でも fsgrab でも、 /mnt/recovered.000 の末尾に不要な情報が付加
されてしまいますが、全く問題はありません。この余分な情報を取り除くには
、 i-node の Size フィールドにある値を取り出し、この値を dd コマンドの
bs オプションに指定するのが最も簡単でしょう。
┌──────────────────────────────────┐
│ # dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065 │
└──────────────────────────────────┘
もちろん、ファイルを構成していたディスクブロックのいくつかは、既に上書
きされてしまっているかもしれません。その場合は運が悪かったとしか言えま
せん。そのブロックを復旧することは不可能です。(パーティションをすばやく
umount できたか否かが勝負の分かれ目です。)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10.2. 大きなファイル
ファイルのデータが 12 ブロック以上ある場合は、ちょっと面倒です。さしあ
たり、先ず UNIX のファイルシステムがどういう構造になっているのかを若干
理解しておく必要があります。ファイルのデータは、「ブロック」と呼ばれる
単位に分割されてディスク上に保存されています。このブロックには、頭から
順に番号が付けられています。また、ファイルは「i-node」という情報も持ち
、i-node にはファイル所有者やパーミッション、ファイルタイプ等の情報が記
載されています。ブロックと同じく i-node にも順に番号が振られていますが
、この二つのシーケンスは全く別のものです。ディレクトリエントリは、ファ
イル名と i-node 番号とからなります。
しかしこれだけでは、カーネルはディレクトリエントリに対応するデータを見
つけることが出来ません。それゆえ i-node には、次のように、ファイルデー
タのブロックの位置に関する情報も記載されるようになっています。
・ 12 データブロック分のブロック番号は、i-node に直接記載されています
。これらのディスクブロックは、直接ブロック(direct block) と呼ばれる
こともあります。
・ i-node には、間接ブロック(indirect block) のブロック番号がひとつ記
載されます。この間接ブロックには、直接ブロックを超過した 256 ブロッ
ク分のブロック番号が記載されています。
・ i-node には、二重間接ブロック(doubly indirect block) のブロック番号
がひとつ記載されます。二重間接ブロックには、上記の間接ブロックを超
過した 256 個分の間接ブロックが記載されています。
・ i-node には、三重間接ブロック(triply indirect block) のブロック番号
がひとつ記載されます。三重間接ブロックには、上記の二重間接ブロック
を超過した 256 個分の二重間接ブロックのブロック番号が記載されていま
す。
以上をもう一度読んでください。確かにややこしいですが、非常に重要です。
現在、バージョン 2.0.36 以降のすべてのカーネルでは、ファイルを削除する
際に間接ブロック (および二重間接ブロック以上) をすべてゼロしてしまうよ
うになっています。それゆえ、12 ブロック以上のファイルの場合、ファイル内
容の復旧どころか、必要なブロック番号を見つけ出せる保証すらありません。
いまのところ著者がたどり着いた唯一の方法は、そのファイルのデータがフラ
グメント化せずに連続して並んでいると仮定して、作業を行ってみるというこ
とです。フラグメント化してしまっている場合は非常にやっかいです。フラグ
メント化していないと仮定するなら、データブロックの並び方には (ファイル
のデータブロック数に対応して) 次のようなパターンが考えられます。
0 から 12 ブロック
上述したように、ブロック番号は、i-node に記載されています。
13 から 268 ブロック
直接ブロックのあとに間接ブロックがひとつあり、その後に 256 個のデー
タブロックが並びます。
269 から 65804 ブロック
上記同様、12 個の直接ブロック、ひとつの (不要な) 間接ブロック、そし
て 256 個のブロックが並びます。その後に、ひとつの (不要な) 二重間接
ブロックがあり、さらにひとつの (不要な) 間接ブロックと 256 個のデー
タブロックという組み合わせが 256 組続きます。
65805 ブロック以上
冒頭の 65804 ブロックまでの並びは上記と同様です。その後に、ひとつの
(不要な) 三重間接ブロックがあり、さらに 256 組の「二重間接シーケン
ス」が続きます。二重間接シーケンスは、(不要な) 二重間接ブロックを先
頭とし、その後にひとつの (不要な) 間接ブロックと 256 個のデータブロ
ックという組み合わせが 256 組続く並びによって構成されます。
もちろん、ここで仮定したデータブロックのブロック番号が正しいとしても、
その中身であるデータそのものが書き換えられていないという保証はありませ
ん。さらに、ファイルが大きくなればなるほど、そのファイルが(特殊な環境を
覗いて) なんらかのフラグメンテーションを起こさずに、ファイルシステムに
書き込まれている可能性は小さくなります。
注意してほしいのは、この文書ではこれまでブロックサイズが標準的な 1024
バイトであると仮定した上で説明しているということです。ブロックサイズを
それ以上に設定している場合、上述の数字は変化します。特に、個々のブロッ
ク番号は 4 バイト長なので、"ブロックサイズ/4" は、個々の間接ブロックに
あるブロック番号の数と一致します。それゆえ、上記の説明で 256 という数字
が現れたときは、必ず "ブロックサイズ/4" に置き換えてください。「必要な
ブロックの数」の境界も変わることになるはずです。
それでは、大きなファイルの復旧例を見てみましょう。
┌─────────────────────────────────────┐
│ debugfs: stat <1387> │
│ Inode: 148004 Type: regular Mode: 0644 Flags: 0x0 Version: 1 │
│ User: 503 Group: 100 Size: 1851347 │
│ File ACL: 0 Directory ACL: 0 │
│ Links: 0 Blockcount: 3616 │
│ Fragment: Address: 0 Number: 0 Size: 0 │
│ ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996 │
│ atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996 │
│ mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996 │
│ dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996 │
│ BLOCKS: │
│ 8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583 │
│ TOTAL: 14 │
└─────────────────────────────────────┘
上記ファイルがフラグメント化していない可能性は、そこそこあるように思わ
れます。 i-node にリストアップされている冒頭の 12 ブロック (これらはす
べてデータブロックです) は確かに連続しています。まずこれらのブロックを
復旧することから始めましょう。
┌──────────────────────────────────┐
│ # fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001 │
└──────────────────────────────────┘
ここで、i-node にリストアップされている次のブロック、すなわち 8326 は間
接ブロックなので無視できます。次にこの間接ブロックに続いて 256 個のデー
タブロックが連続していると信じましょう (8327 番から 8582 番までです)。
┌──────────────────────────────────┐
│ # fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001 │
└──────────────────────────────────┘
i-node に表記された最後のブロックは 8583 です。ここでもまた、ファイルの
データブロックが連続しているものとみなします。上記で書き出した最後のデ
ータブロックは、8327 + 225 = 8582 番でした。次の 8583 ブロックは二重間
接ブロックなので無視できます。そしてこのブロックの後に、間接ブロック
(これは無視) に続く 256 のデータブロックが 256 組続くわけです。これらを
すばやく計算すると、次のコマンドを打つべきだということになります。二重
間接ブロック 8583 と (おそらく) そのすぐ後にある間接ブロック 8584 はス
キップして、データブロックである 8585 から始めている点に注意してくださ
い。
┌──────────────────────────────────┐
│ # fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001 │
│ # fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001 │
│ # fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001 │
│ # fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001 │
│ # fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001 │
│ # fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001 │
└──────────────────────────────────┘
上記をまとめると、これまでに 12 + (7 * 256) 個のブロック、すなわち 1804
個のブロックを書き出したことになります。i-node を stat コマンドで調べた
結果は、'blockcount' で 3616 個と表示されていました。残念ながら、この表
記でのブロック長は (UNIX での伝統を引き継いで) 512 バイトで計算されてい
るので、実際は 1024 バイトで計算すると 3616/2 = 1808 ブロックということ
になります。つまり、あと 4 ブロック足りないだけだということです。最後に
書き出されたブロックは 10125 番であったので、再度これまでと同様に、間接
ブロック(10126 番)をスキップして、それら最後の 4 ブロックを書き出します
。
┌──────────────────────────────────┐
│ # fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001 │
└──────────────────────────────────┘
以上で、運が良ければ、ファイル全体を復旧することに成功したことになりま
す。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
11. i-node を直接いじる
この方法は、表面的には、先ほどよりもずっと簡単です。しかし以前も触れた
通り、 12 ブロック以上の大きなファイルに対しては役に立ちません。
復旧したいファイルそれぞれに対して、usage count を 1 に設定し、deletion
time を 0 に設定します。これには debugfs の mi (modify i-node) コマンド
を使います。例として、これまでと同じく、 i-node 148003 を使って、i-node
の変更処理を説明します。
┌──────────────────────────────────┐
│ debugfs: mi <148003> │
│ Mode [0100644] │
│ User ID [503] │
│ Group ID [100] │
│ Size [6065] │
│ Creation time [833201524] │
│ Modification time [832708049] │
│ Access time [826012887] │
│ Deletion time [833201524] 0 │
│ Link count [0] 1 │
│ Block count [12] │
│ File flags [0x0] │
│ Reserved1 [0] │
│ File acl [0] │
│ Directory acl [0] │
│ Fragment address [0] │
│ Fragment number [0] │
│ Fragment size [0] │
│ Direct Block #0 [594810] │
│ Direct Block #1 [594811] │
│ Direct Block #2 [594814] │
│ Direct Block #3 [594815] │
│ Direct Block #4 [594816] │
│ Direct Block #5 [594817] │
│ Direct Block #6 [0] │
│ Direct Block #7 [0] │
│ Direct Block #8 [0] │
│ Direct Block #9 [0] │
│ Direct Block #10 [0] │
│ Direct Block #11 [0] │
│ Indirect Block [0] │
│ Double Indirect Block [0] │
│ Triple Indirect Block [0] │
└──────────────────────────────────┘
上記で、著者は deletion time に 0 を、link count に 1 を設定し、それ以
外のフィールドではそのままリターンキーを押しました。復旧したいファイル
がたくさんある場合、この方法は確かにちょっと面倒ではありますが、まあな
んとかなると思います。こうした方法を野暮だと思うのなら、かわいい「ゴミ
箱」アイコン付きのグラフィカルな "オペレーティングシステム" の方をとっ
くに使っているはずでしょうから。
ところで、mi コマンドの出力には、Creation time というフィールドがありま
す。これはウソです! (少なくとも誤解の素です。) 実際には、UNIX ファイル
システムではファイルの作成時を知ることはできません。構造体 stat のメン
バである st_ctime は、i-node の更新時間を示すものです。つまり i-node 内
の何らかの情報が最後に変更された時刻を示しているわけです。と、まあ、こ
の話はここまで。
著者が上記の例で使った debugfs よりも新しいバージョンを使う場合は、例題
で示したフィールドのいくつかが省略されるかもしれないので注意してくださ
い(特に、Reserved1 と fragment フィールド (のいくつか) は省略されるよう
です)。
i-node の変更が済んだら、debugfs を終了して、以下のようにしてください。
┌──────────────────────────────────┐
│ # e2fsck -f /dev/hda5 │
└──────────────────────────────────┘
これには次のような意味があります。すなわち、削除されていたおのおのファ
イルは既に文字通り復旧しているのですが、まだディレクトリエントリには表
示されない状態です。e2fsck プログラムはこの状態を検出して、そのファイル
システムの /lost+found ディレクトリ内に個々のファイルのディレクトリエン
トリを追加するようになっています。 (したがってパーティションが通常 /usr
にマウントされるのだとすると、ファイルシステムが次にマウントされた際に
、復旧ファイルは /usr/lost+found に現れるわけです。) ここまで来れば、あ
とはそのファイルの中身からファイル名を割り出して、そのファイルをファイ
ルシステムツリーの適切な場所に戻すだけです。
e2fsck を実行した際には、各種情報が出力されると同時に、どのダメージを修
復すべきかの質問が表示されます。"summary information" もしくは変更した
i-node に関する事柄が表示された場合は、すべて yes で答えてください。そ
れ以外の質問については読者の判断にお任せしますが、通常はすべての質問に
yes で答えておくほうが無難です。e2fsck コマンドが終了したら、ファイルシ
ステムを再マウントできます。
実は、e2fsck を使ってファイルを /lost+found に出現させる以外の方法もあ
ります。debugfs を使えば、そのノードに対するリンクをファイルシステム内
に作成できるのです。i-node を変更した後で debugfs 作成することが可能で
す。i-node を変更した後で、debugfs の link コマンドを使います。
┌──────────────────────────────────┐
│ debugfs: link <148003> foo.txt │
└──────────────────────────────────┘
これによって、debugfs コマンドが正しいと判断したディレクトリ内に
foo.txt という名前のファイルが作成されます。この foo.txt というファイル
が、読者の求めていたファイルとなるはずです。ただこの場合でも、e2fsck を
使って、summary 情報や block count 等を修復する必要があります。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
12. 将来的にはもっと簡単になるでしょうか？
なります。事実、既にそうなってきていると著者は考えています。ただ、先ほ
ど説明したように、現在の安定版カーネル (2.0.x シリーズ) では、i-node の
間接ブロック番号はファイルの削除時にゼロに戻されてしまいます。しかしこ
れは 2.1.x シリーズの開発版カーネルと 2.2.x の安定版カーネルには当ては
まりません。今これを書いている日時が 1999年2月2日なのですが、数日前にカ
ーネル 2.2.1 がリリースされたところです。1, 2 カ月すれば、Linux ベンダ
ーは 2.2.x カーネルを使ったディストリビューションを作りはじめるでしょう
。
安定版カーネルで間接ブロックに伴う困難が克服されれば、著者が手動で
i-node をいじることに反対していた論拠の多くも消失します。同時に、
debugfs 付属の dump コマンドを大きなファイルに対して使用したり、もっと
簡単な他の復旧ツールを使うといったことが可能になるでしょう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
13. 一連のプロセスを自動化するツールはないですか？
あることはあります。ただ残念ながらそれらには、手動で i-node をいじる場
合と同じ問題があります。つまり、間接ブロックのデータを復旧できなないの
です。しかし前述したように、これは遠からず問題にならなくなるかもしれな
いので、ここでそうしたプログラムをざっと眺めてみる価値はあります。
著者は、e2recover というツールを作成しました。これは Perl で書かれた、
実質的には fsgrab のラッパーです。間接ブロックのブロック番号がゼロにさ
れてしまった場合でもファイルを取り扱えるよう工夫をこらしてあり、フラグ
メンテーションさえなければ、非常によい結果をもたらすと思います。また復
旧したファイルのパーミッション (および可能ならファイル所有者についても)
を正しく設定し、復旧されたファイルが元のファイルサイズと一致しているか
否かも確認します。
e2recover は、来るべきこの文書の改訂版のために作成されました。つまり今
のところ、e2recover 用の詳しい解説は、この文書の次回の改訂の際に記載す
るめどしか立っていないということです。ただ、それはそれとして、現状でも
e2recover は役に立つはずです。ダウンロードする場合は著者のウェブサイト
をお使いください。近いうちに
Metalab からもダウンロードできるようになると思います。
Scott D. Heavner は、lde、すなわち the Linux Disk Editor の作者です。こ
れは、バイナリディスクエディタであると同時に、 debugfs の代替ツールとし
て ext2 と minix ファイルシステム、および xia ファイルシステムを扱うこ
とができます (ただし 2.1.x や 2.2.x カーネルでは xia のサポートは打ち切
られています)。そして、ファイルの一連のブロックを辿ったり、ディスク情報
を検索したりして、ファイルの復旧作業を手助けする機能も付いています。ま
た、ファイルシステムの基本的な概念を述べた良質の文書と、復旧の際のツー
ルの使い方を述べた分かり易い文書とが添付されています。lde のバージョン
2.4 は、Metalab やそのミラーサイト、および作成者のウェブサイト から入手できます。
もうひとつの方法として、GNU Midnight Commander, mc があります。これはフ
ルスクリーンのファイル管理ツールであり、著者の知る限り、 'NC' と呼ばれ
ていた MS-DOS プログラムがベースになっています。mc は、Linux コンソール
や xterm 上でのマウス操作をサポートし、さらに仮想ファイルシステムを提供
することで、tar ファイル内にディレクトリを移動するといったトリックも可
能になっています。その仮想ファイルシステムの機能のひとつとして、ext2 で
のファイルの復旧があります。使いやすさは抜群です。ただ、実際のところ、
著者自身は使ってはいません。古き良きのシェルコマンド方式のほうが好きだ
からです。
復旧機能を使うには、プログラムを --with-ext2undel オプションを付けて
configure を実行する必要があります。また e2fsprogs に付属する開発用ライ
ブラリとインクルードファイルも必要になります。Debian GNU/Linux に同梱されている mc は、予めこのオプション付きでビルド
されています。他のディストリビューションでもおそらく同じだと思われます
。プログラムのビルドが済んだら、mc に cd undel:/dev/hda5 と命令して、削
除ファイルの一覧を見ることができます。今日の多くの復旧ツール同様、mc も
ゼロ埋めされた間接ブロックを上手く扱えません。一般に、大きなファイルの
冒頭 12k だけしか復旧できないこともあります。
最新バージョンは、the Midnight Commander の ftp サイト からダウンロードできます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
14. あとがき
書くための時間と、それに値するトピックがある限り、この文書を定期的に更
新していきたいと思っています。つまり、著者は読者からのコメントを切望し
ています。文章がもっと分かり易くならないか、より簡単に解決する方法はな
いか、自動処理をする新しいツールが出ていないか等々、この文書や fsgrab、
e2recover ツールに関する話題があれば、是非 までメー
ルをお送りください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
15. Credit と参考文献
もし私が他人よりも遠くを見ているとするなら、それは、私
が巨人たちの肩の上に立っているからだ。
--Isaac Newton
この mini-HOWTO は、Robin Glover の商標
です。
・ UNIX は、the Open Group の商標です。
・ Linux は、USA その他の国における Linus Torvalds の商標です。
この文書は、Copyright (c) 1997, 1999 Aaron Crane が
著作権を保持しています。この文書の頒布については、この著作権表示自体を
含めた全文全体として、自由に頒布することを許可します。しかし、文書の改
変は、著者もしくは Linux Documentation Project の HOWTO コーディネータ
の許諾がない限り行わないでください。批評や引用目的で、この文書の僅かな
部分を逐語的に複製することは認められています。その場合、文書の複製に際
し、引用元を適切に表示するならば、この著作権表示を記載する必要はありま
せん。
この文書をコンピュータ用の媒体もしくは印刷媒体で販売しようとする場合、
著者自身か Linux HOWTO コーディネータにその計画を事前に知らせてくれるよ
う希望します。ただ、これはあくまで希望です。
現在の Linux HOWTO コーディネータは、Tim Bynum <
linux-howto@metalab.unc.edu> です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
17. 日本語訳について
誤字・脱字・誤訳等は までお知らせください。
翻訳： 吉川雅英 (1997/10/16)
校正： 中野武雄
菊谷誠
更新： 千旦裕司 (2001/09/11)
校正： 中野武雄
一覧に戻る
グリーンネット・トップページへ戻る
|
