<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">

<article>

<artheader>

<title>Linux Ext2fs Undeletion mini-HOWTO</title>

<author>
<firstname>Aaron</firstname>
<surname>Crane</surname>
 <affiliation>
  <address>aaronc@pobox.com</address>
 </affiliation>
</author>

<othercredit>
<firstname>JF Project</firstname>
<surname></surname>
<contrib>日本語訳</contrib>
 <affiliation>
  <address>JF@linux.or.jp</address>
 </affiliation>
</othercredit>

<pubdate>v1.3, 2 February 1999</pubdate>

<abstract>
<para>
<!--
Picture this.  You've spent the last three days with no sleep, no food, not
even a shower.  Your hacking compulsion has at last paid off: you've finished
that program that will bring you world-wide fame and recognition.  All that you
still need to do is tar it up and put it on Metalab.  Oh, and delete all those
Emacs backup files.  So you say <literal>rm * &tilde;</literal>.  And too late,
you notice the extra space in that command.  You've just deleted your 
<emphasis>magnum opus</emphasis>! But help is at hand.  This document presents 
a discussion of how to retrieve deleted files from a Second Extended File 
System.  Just maybe, you'll be able to release that program after all...
-->
次のような状況を想像してほしい。ここ 3 日間、飲まず食わすでシャワーも浴びずに
作業を続け、ようやくその抑えきれないハッキングの衝動が実を結んだ。ついに、
プログラムが完成したのだ。世界的な賞賛と名声をもたらすだろうほどの。
あとは tar でかためて、Metalab にあげるだけだ。おっと、Emacs の
バックアップファイルの削除を忘れていた。ここであなたは、<command>rm * ~
</command> とコマンドを打つ。そして、嗚呼、コマンドに余計な
スペースを入れてしまったことに気付くのである。<emphasis>世紀の逸品</emphasis>
を削除してしまった！ しかし、万策尽きたわけではない。この文書は、Ext2 
ファイルシステム上で削除してしまったファイルを復旧する方法について解説して
いる。おそらく、最後にあなたはそのプログラムをリリースできるはず....
</para>
</abstract>

</artheader>

<sect1 id="introduction">
<title><!--Introduction-->はじめに</title>

<para>
<!--
This mini-Howto attempts to provide hints on how to retrieve deleted files
from an ext2 file system.  It also contains a limited amount of discussion of
how to avoid deleting files in the first place.
-->
この mini-Howto は、ext2 ファイルシステム上で削除してしまったファイルを
復旧する方法について、そのヒントを提供しようとするものです。
また、そもそもファイルを誤って削除しないようにするための予防策についても、
若干説明しています。
</para>

<para>
<!--
I intend it to be useful certainly for people who have just had, shall we say,
a little accident with <literal>rm</literal>; however, I also hope that people 
read it anyway.  You never know: one day, some of the information in here could
save your bacon.
-->
もちろん、たった今 <command>rm</command> コマンドで
「ちょっとした事故」を起こしてしまった人のために、この文書は役に立つでしょう。
とはいえ、いずれにしても多くの読者に本文書を読んでもらいたいとも願っています。
いまはまだわからないでしょうが、
ある日この情報があなたの窮地を救うかもしれないのですから。
</para>

<para>
<!--
The text assumes a little background knowledge about UNIX file systems in
general; however, I hope that it will be accessible to most Linux users.  If
you are an outright beginner, I'm afraid that undeleting files under Linux
<emphasis>does</emphasis> require a certain amount of technical knowledge and 
persistence, at least for the time being.
-->
この文書は、読者が UNIX ファイルシステム全般についてある程度知っている
ことを前提にしていますが、普段 Linux 使っている人ならたいてい意味が分かる
ようにもしたつもりです。もし読者が全くの初心者なら、Linux 上でのファイルの
復旧には、さしあたりかなりの技術的知識と忍耐とが要求されているということを
述べておきます。(訳注：<ulink 
url="http://www.linux.or.jp/JF/JFdocs/The-Linux-Kernel-10.html">
The Linux Kernel</ulink> に比較的詳しい解説があります。)
</para>

<para>
<!--
You will be unable to recover deleted files from an ext2 file system without
at least read access to the raw device on which the file was stored.  In
general, this means that you must be root, but some distributions (such as
<ulink url="http://www.debian.org/">Debian GNU/Linux</ulink>) provide a
<literal>disk</literal> group whose members have access to such devices.  
You also need <literal>debugfs</literal> from the <literal>e2fsprogs</literal> 
package.  This should have been installed by your distribution.
-->
ext2 ファイルシステム上での削除ファイルの復旧には、少なくともそのファイルが
保存されていた生(raw)デバイスに対する読み出しアクセスが不可欠です。一般に
このことは root での作業を意味しますが、(<ulink 
url="http://www.debian.org/">Debian GNU/Linux</ulink> などの)
ディストリビューションのなかには、<literal>disk</literal>
グループに所属しているメンバーなら、
そうしたデバイスにアクセスできるようになっているものもあります。
<filename>e2fsprogs</filename> パッケージにある 
<filename>debugfs</filename> も必要になりますが、
このユーティリティはお使いのディストリビューションに含まれていると思います。
</para>

<para>
<!--
Why have I written this?  It stems largely from my own experiences with a
particularly foolish and disastrous <literal>rm -r</literal> command as root.  
I deleted about 97 JPEG files which I needed and could almost certainly not 
recover from other sources.  Using some helpful tips (see section
<xref linkend="sec-credits">) and a great deal of
persistence, I recovered 91 files undamaged.  I managed to retrieve at least
parts of five of the rest (enough to see what the picture was in each case).
Only one was undisplayable, and even for this one, I am fairly sure that no
more than 1024 bytes were lost (though unfortunately from the beginning of the
file; given that I know nothing about the JFIF file format I had done as much
as I could).
-->
著者がこの文書を書いたのは、<command>rm -r</command> というなんとも
愚かで破壊的なコマンドを root で使ってしまったという個人的な経験に
由来しています。97 個の JPEG ファイルを削除してしまったのです。これらは
是非とも必要で、かつ他から再び取得するのはほとんど
不可能な代物でした。しかし、(<xref linkend="sec-credits"> の章にある) 
tips を使ってかなり粘った結果、91 枚を無傷で復旧できました。残りの画像に
ついても、 5 枚まではなんとか取り戻すことができました (各々がどういう画像か
分かる程度の復旧でした)。最後の一枚だけは表示不能でしたが、これについても
情報欠落を 1024 バイト以下程度にはできたと思っています 
(しかし不運にも欠落した情報はファイルの先頭部分だったのです。
JFIF ファイル形式については何も知らなかった当時としては、
出来るだけのことはやったのですが)。
</para>

<para>
<!--
I shall discuss further below what sort of recovery rate you can expect for
deleted files.
-->
削除ファイルの復旧率として、どの程度の値を期待できるかについては
のちほど議論するつもりです。
</para>

<sect2>
<title><!--Revision history-->更新歴</title>

<para>
<!--
The various publicly-released revisions of this document (and their
publication dates) are as follows:
-->
この文書の公式リリースとそのリリース日は、以下のとおりです。
</para>

<para>
<itemizedlist>
<listitem><para>
<!--
v1.0 on 18 January 1997
-->
v1.0, 1997年1月18日
</para></listitem>

<listitem><para>
<!--
v1.1 on 23 July 1997 (see section
<xref linkend="sec-v1.1">)
-->
v1.1, 1997年7月23日 (<xref linkend="sec-v1.1"> 参照)
</para></listitem>

<listitem><para>
<!--
v1.2 on 4 August 1997 (see section
<xref linkend="sec-v1.2">)
-->
v1.2, 1997年8月4日 (<xref linkend="sec-v1.2"> 参照)
</para></listitem>

<listitem><para>
<!--
v1.3 on 2 February 1999 (see section
<xref linkend="sec-v1.3">)
-->
v1.3, 1999年2月2日 (<xref linkend="sec-v1.3"> 参照)
</para></listitem>

</itemizedlist>
</para>

<sect3 id="sec-v1.1">
<title><!--Changes in version 1.1-->バージョン 1.1 での変更点</title>

<para>
<!--
What changes have been made in this version?  First of all, the thinko in
the example of file recovery has been fixed.  Thankyou to all those who wrote
to point out my mistaek; I hope I've learned to be more careful when making up
program interaction.
-->
バージョン 1.1 での変更点は、なによりも、ファイル復旧の例題にあった
著者の思い違いを訂正したことです。誤りを指摘してくれたすべての方に
感謝します。プログラムの相互作用について書く際には、もっと慎重に
なろうと思います。
</para>

<para>
<!--
Secondly, the discussion of UNIX file system layout has been rewritten to be, I
hope, more understandable.  I wasn't entirely happy with it in the first place,
and some people's comments indicated that it wasn't clear.
-->
二つ目は、UNIX ファイルシステムのレイアウトの説明を書き直したことです。
これによって、おそらくより分かり易くなったと思います。もともと自分でも満足
してはいなかったのと、複数の方からのコメントでも不明瞭との指摘をいただいて
いたからです。
</para>

<para>
<!--
Thirdly, the vast uuencoded gzipped tarball of <literal>fsgrab</literal> in 
the middle of the file has been removed.  The program is now available on
<ulink url="http://pobox.com/&#732;aaronc/tech/fsgrab-1.2.tar.gz">my website
</ulink> and on <ulink url="http://metalab.unc.edu/pub/Linux/utils/file/">
Metalab</ulink>(and mirrors).
-->
三つ目は、文書の中程に uuencode した <filename>fsgrab</filename> の 
gzip tarball があったのを削除したことです。このプログラムは、現在 
<ulink url="http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">著者の
ウェブサイト</ulink> や <ulink 
url="http://metalab.unc.edu/pub/Linux/utils/file/">Metalab</ulink> 
(およびそのミラーサイト)から入手できます。
</para>

<para>
<!--
Fourthly, the document has been translated into the Linux Documentation
Project SGML Tools content markup language.  This markup language can be
easily converted to any of a number of other markup languages (including
HTML and LaTeX) for convenient display and printing.  One benefit of this is
that beautiful typography in paper editions is a much more achievable goal;
another is that the document has cross-references and hyperlinks when viewed
on the Web.
-->
四つ目は、この文書が Linux Documentation Project の SGML Tools に合わせて 
SGML 化されたことです。このマークアップ言語は、スクリーン表示や印刷の
便宜に応じて、(HTML や LaTeX などの)他の複数のマークアップ言語へも
簡単に変換できます。この利点のひとつは、印刷時の美しい版組が
より簡単に実現できるということです。またウェブ上で閲覧する場合には
クロスリファレンスやハイパーリンクが使えます。
</para>

</sect3>

<sect3 id="sec-v1.2">
<title><!--Changes in version 1.2-->バージョン 1.2 での変更点</title>

<para>
<!--
This revision is very much an incremental change.  It's here mainly to
include changes suggested by readers, one of which is particularly important.
-->
この改訂は、おもに項目の追加のためです。主として、読者からの提案による
変更であり、そのひとつは特に重要なものです。
</para>

<para>
<!--
The first change was suggested by Egil Kvaleberg
<literal><ulink url="mailto:egil@kvaleberg.no">egil@kvaleberg.no</ulink>
</literal>, who pointed out the <literal>dump</literal> command in <literal>
debugfs</literal>.  Thanks again, Egil.
-->
第一の変更箇所は、Egil Kvalegerg &lt;egil@kvalengerg.no&gt; からの提案
です。彼は、<command>debugfs</command> の <command>dump</command> コマンド
を指摘してくれました。Egil、どうもありがとう。
</para>

<para>
<!--
The second change is to mention the use of <literal>chattr</literal> for 
avoiding deleting important files.  Thanks to Herman Suijs<literal><ulink
url="mailto:H.P.M.Suijs@kub.nl">H.P.M.Suijs@kub.nl</ulink></literal>
for mentioning this one.
-->
第二の変更箇所は、重要なファイルを削除してしまわないために <command>
chattr</command> コマンドを使うということを指摘した点です。
Herman Suijs &lt;H.P.M.Suijs@kub.nl&gt; からの指摘です。
</para>

<para>
<!--
The abstract has been revised.  URLs have been added for organisations and
software.  Various other minor changes have been made (including fixing typos
and so on).
-->
文書の abstract が改訂されました。いくつかの組織とソフトウェアに関する URL 
も追加しました。(typo の訂正を含む)各種マイナーな変更もありました。
</para>

</sect3>

<sect3 id="sec-v1.3">
<title><!--Changes in version 1.3-->バージョン 1.3 での変更点</title>

<para>
<![IGNORE[
Though it is the first release in 17 months, there is very little that is
new here.  This release merely fixes a few minor errors (typos, dangling
URLs, that sort of thing -- especially the non-link to the Open Group), and
updates a few parts of the text that have become hopelessly out-of-date,
such as the material on kernel versions and on <literal>lde</literal>.  Oh, 
and I've changed `Sunsite' to `Metalab' throughout.
]]>
最初のリリースから 17 カ月経ちましたが、新しい追加事項はほとんどありません。
今回は、小さな間違いをいくつか修正しただけです(typo やリンク切れ等、-- 
特に、Open Group へのリンクがなかったことの修正など)。そして、カーネル
バージョンや <command>lde</command> のバージョンなどあまりにも古くなった
記述を一部更新しました。それと、"Sunsite" を "Metalab" に変更しました。
</para>

<para>
<!--
This release is anticipated to be the last one before release 2.0, which
will hopefully be a full Howto.  I have been working on some substantial
changes which will justify an increment of the major version number.
-->
このリリースは、バージョン 2.0 になる前の最後のリリースだと
考えています。2.0 は、完全な HOWTO 文書になるはずです。メジャーバージョン
番号の繰り上げにふさわしい充分な解説を加えられるよう、目下作業中です。
</para>

</sect3>

</sect2>

<sect2>
<title><!--Canonical locations of this document-->
この文書の正式な公開場所</title>

<para>
<!--
The latest public release of this document should always be available in
on the
<ulink
url="http://metalab.unc.edu/LDP/"
>Linux Documentation Project site</ulink
>
(and mirrors).
-->
この文書の最新の公開バージョンは、必ず次の場所(およびそのミラーサイト)
に掲載する予定です。
</para><para>
<ulink url="http://www.linuxdoc.org/">Linux Documentation Project</ulink>
</para>

<para>
<!--
The latest release is also kept on <ulink url="http://pobox.com/&#732;aaronc/">
my website</ulink> in several formats:
-->
また、最新版は、<ulink url="http://pobox.com/~aaronc/">
著者のウェブサイト</ulink>にも各種フォーマットで掲載されています。
</para>

<para>

<itemizedlist>
<listitem>

<para>
<!--
<ulink
url="http://pobox.com/~aaronc/tech/e2-undel/howto.sgml">SGML source
</ulink>. This is the source as I have written it, using the SGML Tools 
package.
-->
<ulink
url="http://pobox.com/~aaronc/tech/e2-undel/howto.sgml">SGML ソース
</ulink>。これは、著者が SGML Tools パッケージを使って書いたこの文書の
ソースファイルです。
</para>
</listitem>
<listitem>

<para>
<!--
<ulink
url="http://pobox.com/~aaronc/tech/e2-undel/html/">HTML</ulink>.
This is HTML, automatically generated from the SGML source.
-->
<ulink
url="http://pobox.com/~aaronc/tech/e2-undel/html/">HTML</ulink>。
これは、SGML ソースから自動的に生成される HTML バージョンです。
</para>
</listitem>
<listitem>

<para>
<!--
<ulink url="http://pobox.com/~aaronc/tech/e2-undel/howto.txt">Plain text
</ulink>. This is plain text, which is also automatically generated from the 
SGML source.
-->
<ulink url="http://pobox.com/~aaronc/tech/e2-undel/howto.txt">Plain text
</ulink>。これも、SGML ソースから自動的に生成されるテキストバージョンです。
</para>
</listitem>

</itemizedlist>

</para>

</sect2>

</sect1>

<sect1 id="precautions">
<title><!--How not to delete files-->
ファイルを誤って削除しないためには</title>

<para>
<!--
It is vital to remember that Linux is unlike MS-DOS when it comes to
undeletion.  For MS-DOS (and its bastard progeny Windows 95), it is generally
fairly straightforward to undelete a file - the `operating system' (I use the
term loosely) even comes with a utility which automates much of the process.
For Linux, this is not the case.
-->
ファイルの復旧という点に関して、Linux は MS-DOS とは勝手が違うということを
まず肝に銘じてください。MS-DOS (およびその悪魔の子である Windows 95) 
の場合、一般にファイルの復旧はかなり簡単です。復旧処理を自動で行う
ユーティリティが、オペレーティングシステム (まあ、著者はこの用語を
広義の意味で使うわけですが) に付属しているからです。しかし、Linux の場合、
そうはいきません。
</para>

<para>
<!--
So.  Rule number one (the prime directive, if you will) is:
-->
従って、ルール No.1 (そう言いたければ「聖なる誓い」) は
</para>

<para>
<!--
<QUOTE
><literal>KEEP BACKUPS</literal></QUOTE
>
-->
<important><title>鉄則</title><para>
  バックアップを取るべし
</para></important>
</para>

<para>
<![IGNORE[
no matter what.  Think of all your data.  Perhaps, like me, you keep several
years' of accumulated email, contacts, programs, papers on your computer.
Think of how your life would be turned upside down if you had a catastrophic
disk failure, or if -- heaven forbid! -- a malicious cracker wiped your
disks.  This is not unlikely; I have corresponded with a number of people in
just such a situation.  I exhort all right-thinking Linux users to go out
and buy a useful backup device, work out a decent backup schedule, and to
<emphasis>stick to it</emphasis>.  Myself, I use a spare hard disk on a second machine, and
periodically mirror my home directory onto it over the ethernet.  For more
information on planning a backup schedule, read Frisch (1995) (see section
<xref linkend="sec-credits">).
]]>
すなわち、何であれ、バックアップを取るようにすること。
すべてのデータが対象です。著者同様、
読者のコンピュータにはメールその他の交信記録やプログラム、各種文書など、
長年に渡る情報が大量に蓄積されているはずです。もしも突発的なディスク
障害が起こったり、あるいは(縁起でもないですが)悪意を持ったクラッカーに
ディスクの内容を消去されてしまったりした場合、日常生活がどれほど混乱するか
を考えてみてください。決してあり得ないことではありません。現に、著者は
まさにそうした状況に陥った多くの人たちとメールのやり取りをしてきました。
賢明な Linux ユーザは、今すぐ適当なバックアップデバイスを買ってきて、
適切なバックアップスケジュールを立てた上で、それを厳守するようおすすめ
します。著者自身は、サブマシン上の余ったディスクを使って、イーサネット
経由でホームディレクトリを定期的にミラーするようにしています。バックアップ
スケジュールの立て方に関する詳細は、Frish (1995) をご覧下さい (
<xref linkend="sec-credits"> 参照)。
</para>

<para>
<!--
In the absence of backups, what then?  (Or even in the presence of backups:
belt and braces is no bad policy where important data is concerned.)
-->
では、バックアップをしていない場合は、どうすべきでしょうか？
(あるいはバックアップがあったとしても。
重要なデータについては、幾重もの安全対策をとることは悪い考えではありません)
</para>

<para>
<!--
Try to set the permissions for important files to 440 (or less): denying
yourself write access to them means that <literal>rm</literal> requires an explicit
confirmation before deleting.  (I find, however, that if I'm recursively
deleting a directory with <literal>rm -r</literal>, I'll interrupt the program on the first
or second confirmation request and reissue the command as <literal>rm -rf</literal>.)
-->
重要なファイルのパーミッションは 440 (あるいはそれより厳しい値) にしましょう。
書き込みをできなくすれば、 <command>rm
</command> コマンドで削除する前に、削除をするか否かの確認メッセージが
表示されるようになります。(ただ、著者の場合、それでも <command>rm -r
</command> コマンドでディレクトリ内を再帰的に削除する際には、
最初の確認表示の段階でプログラムを停止させて、<command>rm -rf</command> 
コマンドを打ってしまったりします。)
</para>

<para>
<!--
A good trick for selected files is to create a hard link to them in a hidden
directory.  I heard a story once about a sysadmin who repeatedly deleted
<literal>/etc/passwd</literal> by accident (thereby half-destroying the system).  One of
the fixes for this was to do something like the following (as root):
-->
特別なファイルに関しては、隠しディレクトリにハードリンクを作成するのも
よい方法です。これは、あるシステム管理者から聞いた話ですが、彼は 
<filename>/etc/passwd</filename> ファイルを何度か誤って削除したことが
あったそうです (これはシステムにほぼ破壊的なダメージを与えます)。
それに対する対処方法のひとつは、以下のようなものだったそうです 
(これは root で実行します)。
</para>

<para>
<screen>
  # mkdir /.backup
  # ln /etc/passwd /.backup
</screen>
</para>

<para>
<!--
It requires quite some effort to delete the file contents completely: if
you say
-->
こうしておくと、ファイルの内容を完全に消去するのがかなり面倒になります。
もし次のようなコマンドを実行したとしても、
</para>

<para>
<screen>
  # rm /etc/passwd
</screen>
</para>

<para>
<!--
then
-->
その際には、
</para>

<para>
<screen>
  # ln /.backup/passwd /etc
</screen>
</para>

<para>
<!--
will retrieve it.  Of course, this does not help in the event that you
overwrite the file, so keep backups anyway.
-->
とすれば、ファイルを復旧できます。もちろん、ファイルを上書きしてしまうと
この方法は役に立たないので、いずれにしてもバックアップは必要です。
</para>

<para>
<!--
On an ext2 file system, it is possible to use ext2 attributes to protect 
things. These attributes are manipulated with the <literal>chattr</literal> 
command.  There is an `append-only' attribute: a file with this attribute may 
be appended to, but may not be deleted, and the existing contents of the file 
may not be overwritten. If a directory has this attribute, any files or 
directories within it may be modified as normal, but no files may be deleted.  
The `append-only' attribute is set with
-->
ext2 ファイルシステム上では、ext2 の属性を利用してファイルやディレクトリを
保護することができます。この属性の操作には <command>chattr</command> 
コマンドを使います。属性にはまず、「追加のみ可能(append-only)」属性という
のがあります。この属性が付いたファイルは、内容の追加は可能ですが、削除
が出来なくなり、既存の内容を上書きすることもできなくなります。ディレクトリ
にこの属性が付いている場合は、そのディレクトリ内のファイルやサブディレクトリ
は、通常通り変更は可能ですが、ファイルの削除が出来なくなります。
「追加のみ可能」属性は、次のように設定します。
</para>

<para>
<!--
<screen>
$ chattr +a FILE...
</screen>
-->
<screen>
  $ chattr +a ファイル名
</screen>
</para>

<para>
<!--
There is also an `immutable' attribute, which can only be set or cleared by
root.  A file or directory with this attribute may not be modified, deleted,
renamed, or (hard) linked.  It may be set as follows:
-->
また、「変更不可(immutable)」属性というのもあり、これは root 権限でのみ
設定や解除ができるようになっています。この属性が付いたファイルや
ディレクトリは、変更、削除、名前の変更、(ハード)リンクの作成が不可能に
なります。設定は、次のようにします。
</para>

<para>
<!--
<screen>
# chattr +i FILE...
</screen>
-->
<screen>
  # chattr +i ファイル名
</screen>
</para>

<para>
<!--
The ext2fs also provides the `undeletable' attribute (<literal>+u</literal> in 
<literal>chattr</literal>).
The intention is that if a file with that attribute is deleted, instead of
actually being reused, it is merely moved to a `safe location' for deletion at
a later date.  Unfortunately this feature has not yet been implemented in
mainstream kernels; and though in the past there has been some interest in
implementing it, it is not (to my knowledge) available for any current kernels.
-->
ext2fs には、さらに「削除不可(undeletable)」という属性もあります (<command>
chattr</command> に <option>+u</option> を付けて設定します)。意味するところ
は、この属性を付けたファイルが削除された場合、実際に再利用されるかどうかに
関わらず、一旦安全な場所に移動され、一定期間経過後に削除されるというもの
です。ただ残念なことに、この機能はメインストリームのカーネルにはまだ
実装されていません。過去に実装されかけたことはあったのですが、(著者の知る
限り) 現在のカーネルではまだ利用可能とはなっていません。
</para>

<para>
<!--
Some people advocate making <literal>rm</literal> a shell alias or function 
for <literal>rm -i</literal> (which asks for confirmation on <emphasis>every
</emphasis> file you delete).  Indeed, the <ulink
url="http://www.redhat.com/">Red Hat distribution</ulink> does this by
default for all users, including root.  Personally, I cannot stand software
which won't run unattended, so I don't do that.  There is also the problem
that sooner or later, you'll be running in single-user mode, or using a
different shell, or even a different machine, where your <literal>rm</literal> 
function doesn't exist.  If you expect to be asked for confirmation, it is easy
to forget where you are and to specify too many files for deletion.  Likewise,
the various scripts and programs that replace <literal>rm</literal> are, IMHO, 
very dangerous.
-->
<command>rm</command> は <command>rm </command>
<option>-i</option> へのエイリアスとするか、同機能の関数に置き換えるべきだ、
と主張する人もいます (<command>rm </command><option>-i</option> は、ファイル
削除の際に必ず確認を求めます)。実際に <ulink 
url="http://www.redhat.com/">Red Hat</ulink> は、root を含む全ユーザに
対してこの機能をデフォルトで設定しています。しかし、著者の個人的な意見では、
ソフトウェアは命令通り忠実に動くべきだと思っているので、こうした見解には
賛同できません。これには問題もあります。遅かれ早かれ、ユーザはシングル・
ユーザモードで起動したり、別のシェルを使ったり、異なるマシンを利用したり
するはずですが、そうした場合にはこの <command>rm</command> 機能は
無効になります。削除確認の表示が出ることに慣れきっていると、自分が
置かれた状況を考えずに、一度に多数のファイルを削除指定してしまわない
とも限りません。同様に、<command>rm</command> コマンドを各種
スクリプトやプログラムで置き換えるのも、著者の考えでは、危険なこと
だと思います。
</para>

<para>
<!--
A slightly better solution is to start using a package which handles
`recyclable' deletion by providing a command not named <literal>rm</literal>.  
For details on these, see Peek, et al (1993) (see section
<xref linkend="sec-credits">).  These however
still suffer from the problem that they tend to encourage the user to have a
nonchalant attitude to deletion, rather than the cautious approach that is
often required on Unix systems.
-->
もう少しましな方法としては、<command>rm</command> とは別のコマンド名で、
「ゴミ箱」形式の削除ができるようなパッケージを使ってみることです。
詳しくは、Peek, et al (1993) (<xref linkend="sec-credits"> 参照) を
見てください。ただ、これにも問題はあります。
このパッケージの作者は、削除についてユーザが無頓着になるよう奨励している
ように思われるからです。Unix システム上では、むしろ、自己責任に基づく
慎重な運用というアプローチが基本になるはずです。
</para>

</sect1>

<sect1 id="recovery-rate">
<title><!--What recovery rate can I expect?-->
どの程度の復旧率が見込めるのか？</title>

<para>
<!--
That depends.  Among the problems with recovering files on a
high-quality, multi-tasking, multi-user operating system like Linux is that
you never know when someone wants to write to the disk.  So when the
operating system is told to delete a file, it assumes that the blocks used
by that file are fair game when it wants to allocate space for a new file.
(This is a specific example of a general principle for Unix-like systems:
the kernel and the associated tools assume that the users aren't idiots.)
In general, the more usage your machine gets, the less likely you are to be
able to recover files successfully.
-->
場合によります。Linux のような高機能、マルチユーザ、
マルチタスクのオペレーティングシステムでファイルを復旧する場合の問題点の
ひとつは、誰がいつディスクに書き込みをするか分からないということです。
ファイルを削除するよう命令されると、オペレーティングシステムは
そのファイルが占めていたディスクブロックを、新規ファイルに割り当てる
ための空間として認識します。(これは、Unix 系オペレーティングシステム
に見られる一般原則の典型的な例です。つまり、カーネルやその関連ツールは、
ユーザが仕組みを理解した上で作業していることを前提にしているということです。)
一般に、マシンを酷使しているほど、ファイルの復旧は難しくなります。
</para>

<para>
<!--
Also, disk fragmentation can affect the ease of recovering files.  If the
partition containing the deleted files is very fragmented, you are unlikely to
be able to read a whole file.
-->
また、ディスクのフラグメンテーションもファイルの復旧率に影響します。
削除ファイルがフラグメンテーションの激しいパーティションに
あった場合には、そのファイル全体を復旧できる確率は低下します。
</para>

<para>
<!--
If your machine, like mine, is effectively a single-user workstation, and
you weren't doing anything disk-intensive at the fatal moment of deleting
those files, I would expect a recovery rate in the same ball-park as
detailed above.  I retrieved nearly 94&percnt; of the files (and these were
binary files, please note) undamaged.  If you get 80&percnt; or better, you
can feel pretty pleased with yourself, I should think.
-->
もし読者のマシンが (著者のマシンのように) 事実上シングルユーザのワーク
ステーションであり、ファイルを削除してしまった瞬間にディスクを酷使するような
処理が行われていなかったとするなら、冒頭で紹介した著者の場合と同等の
復旧率を達成できると思われます。著者はファイルの 94 % 近くを無傷で
復旧しました (しかもこれらはバイナリです)。おそらく 80 % 以上復旧できれば、
かなり満足できるはずだと思います。
</para>

</sect1>

<sect1 id="two-ways">
<title><!--So, how do I undelete a file?-->
では、どうやって復旧するのか？</title>

<para>
<!--
The procedure principally involves finding the data on the raw partition 
device and making it visible again to the operating system.  There are
basically two ways of doing this: one is to modify the existing file system 
such that the deleted inodes have their `deleted' flag removed, and hope that 
the data just magically falls back into place. The other method, which is safer
but slower, is to work out where the data lies in the partition and write it
out into a new file on another file system.
-->
復旧作業の主要な部分は、raw パーティションデバイスからデータを見つけだして、
+それをオペレーティングシステムが認識できるようにすることです。
+これには基本的に二種類の方法があります。ひとつは、
現在のファイルシステム上にある削除されたファイルの i ノードをいじって 
'deleted' フラグを取り除き、データが魔法のようにもとの場所に
戻ってくるように祈る、というものです。もうひとつの、より安全ではありますが
時間のかかる方法は、パーティション内にあるデータを探し出して、
別のファイルシステム上の新規ファイルにそのデータを書き出すというものです。
</para>

<para>
<!--
There are some steps you need to take before beginning to
attempt your data recovery; see sections
<xref linkend="sec-umount">,
<xref linkend="sec-prep-chg"> and
<xref linkend="sec-prep-wrt"> for details.
To find out how to actually retrieve your files, see sections
<xref linkend="sec-finding">,
<xref linkend="sec-obtain">,
<xref linkend="sec-recover"> and
<xref linkend="sec-modify">.
-->
ただし、データ復旧に取りかかる前に、やっておくべき作業が何段階かあります。
詳細は、<xref linkend="sec-umount">,
<xref linkend="sec-prep-chg"> および
<xref linkend="sec-prep-wrt"> をご覧ください。
実際にファイルを復旧する方法は、
<xref linkend="sec-finding">,
<xref linkend="sec-obtain">,
<xref linkend="sec-recover">, 
<xref linkend="sec-modify"> を参照してください。
</para>

</sect1>

<sect1 id="sec-umount">
<title><!--Unmounting the file system-->
ファイルシステムのマウント解除</title>

<para>
<!--
Regardless of which method you choose, the first step is to unmount the
file system containing the deleted files.  I strongly discourage any urges
you may have to mess around on a mounted file system.  This step should be
performed <emphasis>as soon as possible</emphasis> after you realise that the files have
been deleted; the sooner you can unmount, the smaller the chance that your
data will be overwritten.
-->
どちらの方法を使うにせよ、まず最初に削除したファイルが入っているファイル
システムのマウントを解除する必要があります。ここで慌てると、ファイルシステム
をめちゃめちゃにしてしまう可能性があるので注意してください。
この作業は、ファイルを削除してしまったことに気が付いた時点で <emphasis>
出来る限りすばやく</emphasis> 行わなければなりません。マウント解除が早ければ
早いほど、データが上書きされる可能性も少なくなります。
</para>

<para>
<!--
The simplest method is as follows: assuming the deleted files were in the
<literal>/usr</literal> file system, say:
-->
最も簡単な方法は、次のようなものです。ここでは、削除したファイルが 
<filename>/usr</filename> にあるものと仮定しています。
</para>

<para>

<screen>
  # umount /usr
</screen>

</para>

<para>
<!--
You may, however, want to keep some things in <literal>/usr</literal> 
available.  So remount it read-only:
-->
しかし、<filename>/usr</filename> 以下に置かれているものが使えなくなる
のは困るかもしれません。その場合、read-only で再マウントします。
</para>

<para>
<screen>
  # mount -o ro,remount /usr
</screen>
</para>

<para>
<!--
If the deleted files were on the root partition, you'll need to add a 
<literal>-n</literal>
option to prevent mount from trying to write to <literal>/etc/mtab</literal>:
-->
削除したファイルがルートパーティション上にある場合は、<option>-n</option> 
オプションを付けて、<filename>/etc/mtab</filename> ファイルへの書き込みを
避ける必要があります。
</para>

<para>
<screen>
  # mount -n -o ro,remount /
</screen>
</para>

<para>
<!--
Regardless of all this, it is possible that there will be another process using
that file system (which will cause the unmount to fail with an error such as
`Resource busy').  There is a program which will send a signal to any process
using a given file or mount point: <literal>fuser</literal>.  Try this for the 
<literal>/usr</literal> partition:
-->
どの方法でマウント解除するかに関わりなく、他のプロセスが当該のファイルシステム
を使っている可能性もあります (その場合、マウント解除は失敗し、
"Resource busy" のエラーが表示されます)。こういう時のために、特定のファイル
やマウントポイントを使っているプロセスに対してシグナルを送るプログラムが
存在します。<command>fuser</command> です。これを <filename>/usr</filename> 
パーティションに対して使ってみましょう。
</para>

<para>
<screen>
  # fuser -v -m /usr
</screen>
</para>

<para>
<!--
This lists the processes involved.  Assuming none of them are vital, you
can say
-->
上記コマンドによって、対象となるプロセスが列記されます。重要なプロセスが
存在しないことが確認できたら、次のコマンドを実行します。
</para>

<para>
<screen>
  # fuser -k -v -m /usr
</screen>
</para>

<para>
<!--
to send each process a <literal>SIGKILL</literal> (which is guaranteed to 
kill it), or for example,
-->
こうすると個々のプロセスに <literal>SIGKILL</literal> シグナルを送ります 
(これはプロセスを確実に殺すシグナルです)。あるいは、次のように
しても結構です。
</para>

<para>
<screen>
  # fuser -k -TERM -v -m /usr
</screen>
</para>

<para>
<!--
to give each one a <literal>SIGTERM</literal> (which will normally make the 
process exit cleanly).
-->
これは個々のプロセスに <literal>SIGTERM</literal> シグナルを送ります 
(これはプロセスを正常に終了させるシグナルです)。
</para>

</sect1>

<sect1 id="sec-prep-chg">
<title><!--Preparing to change inodes directly-->
i-node を直接書き換える場合の準備</title>

<para>
<!--
My advice?  Don't do it this way.  I really don't think it's wise to play
with a file system at a low enough level for this to work.  This method also
has problems in that you can only reliably recover the first 12 blocks of
each file.  So if you have any long files to recover, you'll normally have
to use the other method anyway.  (Although see section
<xref linkend="sec-easier"> for additional
information.)
-->
著者としては、この方法はおすすめしません。これはファイルシステムの低レベル
層をいじるわけですが、そういうやり方が賢明だとは思えないからです。また
この方法では、確実に復旧できるのは個々のファイルの最初の 12 ブロックだけ
なのです。したがって、大きなファイルを復旧する際は、通常、
最終的に他の方法を使わざるを得ません。(とはいえ、詳しい情報は、
<xref linkend="sec-easier"> をご覧ください。)
</para>

<para>
<!--
If you feel you must do it this way, my advice is to copy the raw partition
data to an image on a different partition, and then mount this using loopback:
-->
どうしてもこの方法を使わないと気が済まない場合は、
raw パーティションのデータを他のパーティション上にディスクイメージとして
コピーし、そのイメージを loopback を使ってマウントすることをおすすめ
します。
</para>

<para>
<screen>
  # cp /dev/hda5 /root/working
  # mount -t ext2 -o loop /root/working /mnt
</screen>
</para>

<para>
<!--
(Note that obsolete versions of <literal>mount</literal> may have problems 
with this.  If your <literal>mount</literal> doesn't work, I strongly suggest 
you get the latest version, or at least version 2.7, as some very old versions 
have severe security bugs.)
-->
(注意してほしいのは、<command>mount</command> コマンドのバージョンが
古いと、上記のコマンドで問題が生じるかもしれないということです。
<command>mount</command> が上手く動かない場合、最新バージョンか、少なくとも 
version 2.7 以上に更新することを強くおすすめします。古いバージョンには、
致命的なセキュリティ上のバグがあるからです。)
</para>

<para>
<!--
Using loopback means that if and when you completely destroy the file
system, all you have to do is copy the raw partition back and start over.
-->
このように loopback を使っておくと、
そのファイルシステムを完全に破壊してしまった場合でも、
raw パーティションを再度コピーしてやり直すだけで済みます。
</para>

</sect1>

<sect1 id="sec-prep-wrt">
<title><!--Preparing to write data elsewhere-->
別の場所にデータを書き出す場合の準備</title>

<para>
<![IGNORE[
If you chose to go this route, you need to make sure you have a rescue
partition somewhere -- a place to write out new copies of the files you
recover.  Hopefully, your system has several partitions on it: perhaps a
root, a <literal>/usr</literal>, and a <literal>/home</literal>.  With all 
these to choose from,
you should have no problem: just create a new directory on one of these.
]]>
別の場所にデータを書き出す方法を取る場合は、まずレスキューパーティションが
あるかどうかを確認する必要があります。つまり、復旧したいファイルのコピー
を書き出す場所を確保するわけです。おそらく、読者のシステムには複数の
パーティションがあり、ルートや <filename>/usr</filename>、<filename>
/home</filename> は別々のパーティションに分かれていると思います。
このうちのひとつを使っても、全く問題ないはずです。どれかひとつの
パーティション上に、新規のディレクトリを作成しましょう。
</para>

<para>
<!--
If you have only a root partition, and store everything on that, things are
slightly more awkward.  Perhaps you have an MS-DOS or Windows partition you
could use?  Or you have the ramdisk driver in your kernel, maybe as a
module?  To use the ramdisk (assuming a kernel more recent than 1.3.48), say
the following:
-->
ルートパーティションしかなくて、すべてをそこに保存している場合は、
若干面倒です。それでも MS-DOS や Windows のパーティションが使えたり、
もしくはカーネルモジュールとして ramdisk ドライバを使えるようには
なっているのではないでしょうか？ ramdisk を使うには 
(これは、1.3.48 以降のカーネルであることが前提です) 次のようにします。
</para>

<para>
<screen>
  # dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
  # mke2fs -v -m 0 /dev/ram0 2048
  # mount -t ext2 /dev/ram0 /mnt
</screen>
</para>

<para>
<!--
This creates a 2MB ramdisk volume, and mounts it on <literal>/mnt</literal>.
-->
これによって 2 MB の ramdisk 領域が作成され、<filename>/mnt</filename> 
上にマウントされます。
</para>

<para>
<!--
A short word of warning: if you use <literal>kerneld</literal> (or its 
replacement <literal>kmod</literal> in 2.2.x and later 2.1.x kernels) to 
automatically load and unload kernel modules, then don't unmount the ramdisk 
until you've copied any files from it onto non-volatile storage.  Once you 
unmount it, <literal>kerneld</literal>
assumes it can unload the module (after the usual waiting period), and once
this happens, the memory gets re-used by other parts of the kernel, losing
all the painstaking hours you just spent recovering your data.
-->
少々注意: 読者が <filename>kerneld</filename> (もしくは、
2.2.x や 2.1.x 以降のカーネルを使っているならその後継である <filename>kmod
</filename>) を使ってカーネルモジュールをロードしている場合、ramdisk 領域
から不揮発性ストレージへのコピーが終了するまで ramdisk のマウントを解除
してはいけません。ramdisk 領域のマウントを解除すると、<filename>kerneld
</filename> はモジュールを (一定時間経過後に) アンロードできるものと思って
しまい、さらに実際にアンロードされてしまうと、ramdisk のメモリ領域は
カーネルの他の部分に再利用されてしまって、苦労してデータの復旧に費やした
時間が全く無駄になってしまうからです。
</para>

<para>
<!--
If you have a Zip, Jaz, or LS-120 drive, or something similar, it would
probably be a good choice for a rescue partition location.  Otherwise,
you'll just have to stick with floppies.
-->
Zip や Jaz, LS-120 といったリムーバブル装置を持っているなら、レスキュー
パーティションの置き場所として是非利用してください。持っていない場合は、
フロッピーでいきましょう。
</para>

<para>
<!--
The other thing you're likely to need is a program which can read the
necessary data from the middle of the partition device.  At a pinch, <literal>
dd</literal> will do the job, but to read from, say, 600 MB into an 800 MB 
partition, <literal>dd</literal> insists on reading but ignoring the first 600 
MB.  This takes a not inconsiderable amount of time, even on fast disks.  
My way round this was to write a program which will seek to the middle of the 
partition.  It's called <literal>fsgrab</literal>; you can find the source 
package on <ulink
url="http://pobox.com/&#732;aaronc/tech/fsgrab-1.2.tar.gz">my website</ulink>
or on <ulink url="http://metalab.unc.edu/pub/Linux/utils/file/">Metalab
</ulink> (and mirrors).  
If you want to use this method, the rest of this mini-Howto
assumes that you have <literal>fsgrab</literal>.
-->
他に必要になるのは、パーティションデバイス上から必要なデータを読み出せる
プログラムです。いざとなれば <command>dd</command> 
でも出来るのですが、でも例えば、パーティションの 600 MB 目から 800MB 目までの
領域を読み出そうとするような場合、dd は最初の 600 MB の領域を無視できず、
どうしても頭から読み込もうとしてしまうのです。高速なディスクを使っている
場合でも、これにはかなりの時間が掛かります。この振る舞いをなんとかしようと
して、著者は、パーティションの途中にある領域を適切に読み出しできる
プログラムを作成しました。<filename>fsgrab</filename> という名前の
プログラムです。このプログラムのソースパッケージは、<ulink
url="http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz">著者のウェブサイト
</ulink> や <ulink url="http://metalab.unc.edu/pub/Linux/utils/file/">Metalab
</ulink> (とそのミラーサイト) にあります。読者がこの方法を使ってくれる
ものと仮定して、ここから先は、読者が <filename>fsgrab</filename> を
持っているものとして説明します。
</para>

<para>
<!--
If none of the files you are trying to recover were more than 12 blocks long
(where a block is usually one kilobyte), then you won't need <literal>fsgrab
</literal>.
-->
ただ、復旧しようとしているファイルの大きさがどれも 12 ディスクブロックを
超えない場合 (1 ディスクブロックは通常 1 Kb です)、<filename>fsgrab
</filename> は不要です。
</para>

<para>
<!--
If you need to use <literal>fsgrab</literal> but don't want to download and 
build it, it is fairly straightforward to translate an <literal>fsgrab
</literal> command-line to one for <literal>dd</literal>.  If we have
-->
<filename>fsgrab</filename> が必要だがダウンロードとビルドがイヤな場合は、
<filename>fsgrab</filename> のコマンドラインを <filename>dd</filename> 
のコマンドラインに置き換えて考えてください。例えば、<filename>
fsgrab</filename> のコマンドラインが以下のような場合、
</para>

<para>
<screen>
  fsgrab -c <emphasis>count</emphasis> -s <emphasis>skip</emphasis> <emphasis>device</emphasis>
</screen>
</para>

<para>
<!--
then the corresponding (but typically much slower) <literal>dd</literal> 
command is
-->
これに相当する <filename>dd</filename> のコマンドラインは (おそらく処理時間が
余分に掛かりますが) 次にようになります。
</para>

<para>

<screen>
  dd bs=1k if=<emphasis>device</emphasis> count=<emphasis>count</emphasis> skip=<emphasis>skip</emphasis>
</screen>

</para>

<para>
<!--
I must warn you that, although <literal>fsgrab</literal> functioned perfectly 
for me, I can take no responsibility for how it performs.  It was really a 
very quick and dirty kludge just to get things to work.  For more details on 
the lack of warranty, see the `No Warranty' section in the <literal>COPYING
</literal> file included with it (the GNU General Public Licence).
-->
ここで一応警告しておきます。<filename>fsgrab</filename> プログラムは、
著者のもとでは完璧に機能しましたが、読者のもとでどのような振る舞いを
しようとも著者は一切責任を負えません。実際これは、きちっと設計された
プログラムではなく、なんとか処理をこなすだけものにすぎません。免責
に関する詳細は、プログラム付属の <filename>COPYRIGHT</filename> 
ファイルに記載された "No Warranty" の章をご覧ください (the GNU General 
Public License です)。
</para>

</sect1>

<sect1 id="sec-finding">
<title><!--Finding the deleted inodes-->削除した i-node を
見つけだす</title>

<para>
<!--
The next step is to ask the file system which inodes have recently been
freed.  This is a task you can accomplish with <literal>debugfs</literal>.  
Start <literal>debugfs</literal> with the name of the device on which the 
file system is stored:
-->
次に踏むべき手順は、ファイルシステムを走査して、どの i-node 
が最近解放されたのかを調べることです。この作業を実行するには <command>debugfs
</command> を使います。<command>debugfs</command> にファイルシステムが
保存されているデバイスのデバイスファイル名を付けて起動してください。
</para>

<para>
<screen>
  # debugfs /dev/hda5
</screen>
</para>

<para>
<!--
If you want to modify the inodes directly, add a <literal>-w</literal> option 
to enable writing to the file system:
-->
i-node を直接変更したい場合は、<option>-w</option> オプションを付けて
ファイルシステムへの書き込みができるようにします。
</para>

<para>
<screen>
  # debugfs -w /dev/hda5
</screen>
</para>

<para>
<!--
The <literal>debugfs</literal> command to find the deleted inodes is <literal>
lsdel</literal>.  So, type the command at the prompt:
-->
削除した i-node を探すための <command>debugfs</command> のコマンドは 
<command>lsdel</command> です。プロンプトから次のように打ち込んで
ください。
</para>

<para>
<screen>
  debugfs:  lsdel
</screen>
</para>

<para>
<!--
After much wailing and grinding of disk mechanisms, a long list is piped into
your favourite pager (the value of <literal>&dollar;PAGER</literal>).  Now 
you'll want to save a copy of this somewhere else.  If you have <literal>less
</literal>, you can type <literal>-o</literal> followed by the name of an 
output file.  Otherwise, you'll have to arrange to send the output elsewhere.  
Try this:
-->
ディスク装置へのアクセス音がしばらく続いた後で、長い i-node のリストがパイプ
処理され、(<envar>$PAGER</envar> で設定した) ページャに表示されます。この
リストを別の場所に保存したい場合、<filename>less</filename> を使っている
なら、<option>-o</option> オプションの後に出力ファイル名を指定します。
<filename>less</filename> 以外を使っているなら、出力を別の
場所に送る必要があります。次のようにしてください。
</para>

<para>

<screen>
  debugfs:  quit
  # echo lsdel | debugfs /dev/hda5 &#62; lsdel.out
</screen>

</para>

<para>
<!--
Now, based only on the deletion time, the size, the type, and the numerical
permissions and owner, you must work out which of these deleted inodes are the
ones you want.  With luck, you'll be able to spot them because they're the big
bunch you deleted about five minutes ago.  Otherwise, trawl through that list
carefully.
-->
ここで、削除日時、ファイルサイズ、ファイルタイプ、パーミッションの数値、
ファイル所有者などの情報だけに基づいて、復旧したいファイルがどれなのかを
見つけださなければなりません。運良く、五分ほど前に削除した大きなファイル
等であれば、比較的簡単に見つけだすことができるでしょう。もしそうでなければ、
リストをしらみつぶしにあたっていきましょう。
</para>

<para>
<!--
I suggest that if possible, you print out the list of the inodes you want to
recover.  It will make life a lot easier.
-->
可能なら、i-node のリストをプリントアウトすることをおすすめします。
調べるのがずっと楽になります。
</para>

</sect1>

<sect1 id="sec-obtain">
<title><!--Obtaining the details of the inodes-->
i-node の詳細を調べる</title>

<para>
<!--
<literal>debugfs</literal> has a <literal>stat</literal> command which prints 
details about an inode. Issue the command for each inode in your recovery 
list.  For example, if you're interested in inode number 148003, try this:
-->
<command>debugfs</command> には <command>stat</command> コマンドがあり、
これを使うと i-node の詳細を表示することができます。
復旧リストにあるそれぞれの i-node に対して <command>stat</command> 
コマンドを実行してください。例えば、i-node 番号 148003 を調べようとする
場合は、次のようにします。
</para>

<para>
<screen>
  debugfs:  stat &#60;148003&#62;
  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
</screen>
</para>

<para>
<!--
If you have a lot of files to recover, you'll want to automate this.  Assuming
that your <literal>lsdel</literal> list of inodes to recover in is in <literal>
lsdel.out</literal>, try this:
-->
復旧したいファイルがたくさんあるなら、上記の手続きを自動化したいと
お思いでしょう。<command>lsdel</command> で作成した復旧リストが <filename>
lsdel.out</filename> ファイルに入っているとするなら、まず次のようにします。
</para>

<para>
<screen>
  # cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " &#62; inodes
</screen>
</para>

<para>
<!--
This new file <literal>inodes</literal> contains just the numbers of the 
inodes to recover, one per line.  We save it because it will very likely come 
in handy later on. Then you just say:
-->
これによって作成された <filename>inodes</filename> ファイルには、
復旧すべき i-node の i-node 番号だけが一行にひとつずつ記述されています。
この情報をファイルに保存したのは、その方が後々便利だからです。そして
次に、以下のようにします。
</para>

<para>
<screen>
  # sed 's/^.*$/stat &#60;\0&#62;/' inodes | debugfs /dev/hda5 &#62; stats
</screen>
</para>

<para>
<!--
and <literal>stats</literal> contains the output of all the <literal>stat
</literal> commands.
-->
以上で <filename>stats</filename> ファイルに、<command>stat</command> 
コマンドの出力結果が全て記録されます。
</para>

</sect1>

<sect1 id="sec-recover">
<title><!--Recovering data blocks-->
データブロックの復旧</title>

<para>
<!--
This part is either very easy or distinctly less so, depending on whether
the file you are trying to recover is more than 12 blocks long.
-->
ここでの手順は、復旧しようとするファイルの大きさが 12 ディスクブロック以下
であるか否かによって、非常に簡単にもなり、逆に面倒にもなり得ます。
</para>

<sect2>
<title><!--Short files-->小さなファイル</title>

<para>
<!--
If the file was no more than 12 blocks long, then the block numbers of all
its data are stored in the inode: you can read them directly out of the
<literal>stat</literal> output for the inode.  Moreover, <literal>debugfs
</literal> has a command which performs this task automatically.  To take the 
example we had before, repeated here:
-->
ファイルのサイズが 12 ブロック以下なら、ファイルのデータを保持している
ブロックナンバーのすべてが、検出した i-node の中に書き込まれています。
その i-node に対して <command>stat</command> を実行すると、
ブロックナンバーを直接読み出すことができます。
さらに <command>debugfs</command> には、
この処理を自動化するコマンドも組み込まれています。
前章で取り上げた例をここでも使って説明します。
</para>

<para>
<screen>
  debugfs:  stat &#60;148003&#62;
  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
</screen>
</para>

<para>
<!--
This file has six blocks.  Since this is less than the limit of 12, we get
<literal>debugfs</literal> to write the file into a new location, such as
<literal>/mnt/recovered.000</literal>:
-->
上記ファイルは 6 つのブロックから成り立っています。12 ブロックという
限度以下なので、<command>debugfs</command> コマンドを使ってこの
ファイルを別の場所、ここでは <filename>/mnt/recovered.000</filename> 
に書き出すことができます。
</para>

<para>
<screen>
  debugfs:  dump &#60;148003&#62; /mnt/recovered.000
</screen>
</para>

<para>
<!--
Of course, this can also be done with <literal>fsgrab</literal>; I'll present 
it here as an example of using it:
-->
もちろん <command>fsgrab</command> コマンドでも同様の処理が可能です。
<command>fsgrab</command> の場合は、次のようにします。
</para>

<para>
<screen>
  # fsgrab -c 2 -s 594810 /dev/hda5 &#62; /mnt/recovered.000
  # fsgrab -c 4 -s 594814 /dev/hda5 &#62;&#62; /mnt/recovered.000
</screen>
</para>

<para>
<!--
With either <literal>debugfs</literal> or <literal>fsgrab</literal>, there 
will be some garbage at the end of <literal>/mnt/recovered.000</literal>, but 
that's fairly unimportant.  If you want to get rid of it, the simplest method 
is to take the <literal>Size</literal> field from the inode, and plug it into 
the <literal>bs</literal> option in a <literal>dd</literal> command line:
-->
<command>debugfs</command> でも <command>fsgrab</command> でも、
<filename>/mnt/recovered.000</filename> の末尾に不要な情報が付加されて
しまいますが、全く問題はありません。この余分な情報を取り除くには、
i-node の <literal>Size</literal> フィールドにある値を取り出し、
この値を <command>dd</command> コマンドの 
<option>bs</option> オプションに指定するのが最も簡単でしょう。
</para>

<para>
<screen>
  # dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
</screen>
</para>

<para>
<!--
Of course, it is possible that one or more of the blocks that made up your file
has been overwritten.  If so, then you're out of luck: that block is gone
forever.  (But just imagine if you'd unmounted sooner!)
-->
もちろん、ファイルを構成していたディスクブロックのいくつかは、既に上書き
されてしまっているかもしれません。その場合は運が悪かったとしか言えません。
そのブロックを復旧することは不可能です。(パーティションをすばやく umount 
できたか否かが勝負の分かれ目です。)
</para>

</sect2>

<sect2>
<title><!--Longer files-->大きなファイル</title>

<para>
<!--
The problems appear when the file has more than 12 data blocks.  It pays
here to know a little of how UNIX file systems are structured.  The file's data
is stored in units called `blocks'.  These blocks may be numbered sequentially.
A file also has an `inode', which is the place where information such as owner,
permissions, and type are kept.  Like blocks, inodes are numbered sequentially,
although they have a different sequence.  A directory entry consists of the
name of the file and an inode number.
-->
ファイルのデータが 12 ブロック以上ある場合は、ちょっと面倒です。さしあたり、
先ず UNIX のファイルシステムがどういう構造になっているのかを若干理解しておく
必要があります。ファイルのデータは、「ブロック」と呼ばれる単位に分割されて
ディスク上に保存されています。このブロックには、頭から順に番号が付けられて
います。また、ファイルは「i-node」という情報も持ち、i-node にはファイル
所有者やパーミッション、ファイルタイプ等の情報が記載されています。ブロック
と同じく i-node にも順に番号が振られていますが、
この二つのシーケンスは全く別のものです。
ディレクトリエントリは、ファイル名と i-node 番号とからなります。
</para>

<para>
<!--
But with this state of affairs, it is still impossible for the kernel to find
the data corresponding to a directory entry.  So the inode also stores the
location of the file's data blocks, as follows:
-->
しかしこれだけでは、カーネルはディレクトリエントリに対応するデータを
見つけることが出来ません。それゆえ i-node には、次のように、ファイル
データのブロックの位置に関する情報も記載されるようになっています。
</para>

<para>

<itemizedlist>

<listitem><para>
<!--
The block numbers of the first 12 data blocks are stored directly in the
inode; these are sometimes referred to as the <emphasis>direct block
</emphasis>s.
-->
12 データブロック分のブロック番号は、i-node に直接記載されています。
これらのディスクブロックは、<emphasis>直接ブロック</emphasis>(direct block) 
と呼ばれることもあります。
</para></listitem>

<listitem><para>
<!--
The inode contains the block number of an <emphasis>indirect block</emphasis>. 
An indirect block contains the block numbers of 256 additional data blocks.
-->
i-node には、<emphasis>間接ブロック</emphasis>(indirect block) のブロック
番号がひとつ記載されます。この間接ブロックには、直接ブロックを超過した 
256 ブロック分のブロック番号が記載されています。
</para></listitem>

<listitem><para>
<!--
The inode contains the block number of a <emphasis>doubly indirect block
</emphasis>.  A doubly indirect block contains the block numbers of 256 
additional indirect blocks.
-->
i-node には、<emphasis>二重間接ブロック</emphasis>(doubly indirect block) 
のブロック番号がひとつ記載されます。二重間接ブロックには、上記の間接ブロック
を超過した 256 個分の間接ブロックが記載されています。
</para></listitem>

<listitem><para>
<!--
The inode contains the block number of a <emphasis>triply indirect block
</emphasis>.  A triply indirect block contains the block numbers of 256 
additional doubly indirect blocks.
-->
i-node には、<emphasis>三重間接ブロック</emphasis>(triply indirect block) 
のブロック番号がひとつ記載されます。三重間接ブロックには、上記の二重間接
ブロックを超過した 256 個分の二重間接ブロックのブロック番号が記載されています。
</para></listitem>

</itemizedlist>

</para>

<para>
<!--
Read that again: I know it's complex, but it's also important.
-->
以上をもう一度読んでください。確かにややこしいですが、非常に重要です。
</para>

<para>
<!--
Now, the kernel implementation for all versions up to and including 2.0.36
unfortunately zeroes all indirect blocks (and doubly indirect blocks, and so
on) when deleting a file.  So if your file was longer than 12 blocks, you
have no guarantee of being able to find even the numbers of all the blocks
you need, let alone their contents.
-->
現在、バージョン 2.0.36 以降のすべてのカーネルでは、ファイルを削除する際に
間接ブロック (および二重間接ブロック以上) を
すべてゼロしてしまうようになっています。それゆえ、12 ブロック以上の
ファイルの場合、ファイル内容の復旧どころか、必要なブロック番号を見つけ出せる
保証すらありません。
</para>

<para>
<!--
The only method I have been able to find thus far is to assume that the file
was not fragmented: if it was, then you're in trouble.  Assuming that the file
was not fragmented, there are several layouts of data blocks, according to how
many data blocks the file used:
-->
いまのところ著者がたどり着いた唯一の方法は、そのファイルのデータがフラグメント
化せずに連続して並んでいると仮定して、作業を行ってみるということです。
フラグメント化してしまっている場合は非常にやっかいです。フラグメント化
していないと仮定するなら、データブロックの並び方には (ファイルの
データブロック数に対応して) 次のようなパターンが考えられます。
</para>

<para>
<variablelist>

<varlistentry>
<term><!--0 to 12-->0 から 12 ブロック</term>
<listitem><para>
<!--
The block numbers are stored in the inode, as described above.
-->
上述したように、ブロック番号は、i-node に記載されています。
</para></listitem>
</varlistentry>

<varlistentry>
<term><!--13 to 268-->13 から 268 ブロック</term>
<listitem><para>
<!--
After the direct blocks, count one for the indirect block, and
then there are 256 data blocks.
-->
直接ブロックのあとに間接ブロックがひとつあり、その後に 256 個の
データブロックが並びます。
</para></listitem>
</varlistentry>

<varlistentry>
<term><!--269 to 65804-->269 から 65804 ブロック</term>
<listitem>
<para>
<!--
As before, there are 12 direct blocks, a (useless) indirect
block, and 256 blocks.  These are followed by one (useless) doubly indirect
block, and 256 repetitions of one (useless) indirect block and 256 data blocks.
-->
上記同様、12 個の直接ブロック、ひとつの (不要な) 間接ブロック、そして 256 個
のブロックが並びます。その後に、ひとつの (不要な) 二重間接ブロックがあり、
さらにひとつの (不要な) 間接ブロックと 256 個のデータブロックという組み合わせ
が 256 組続きます。
</para></listitem>
</varlistentry>

<varlistentry>
<term><!--65805 or more-->65805 ブロック以上</term>
<listitem><para>
<!--
The layout of the first 65804 blocks is as above.  Then
follow one (useless) triply indirect block and 256 repetitions of a `doubly
indirect sequence'.  Each doubly indirect sequence consists of a (useless)
doubly indirect block, followed by 256 repetitions of one (useless) indirect
block and 256 data blocks.
-->
冒頭の 65804 ブロックまでの並びは上記と同様です。その後に、ひとつの(不要な)
三重間接ブロックがあり、さらに 256 組の「二重間接シーケンス」が
続きます。二重間接シーケンスは、(不要な) 二重間接ブロックを先頭とし、その後に
ひとつの (不要な) 間接ブロックと 256 個のデータブロックという組み合わせが 256 
組続く並びによって構成されます。
</para></listitem>
</varlistentry>

</variablelist>
</para>

<para>
<!--
Of course, even if these assumed data block numbers are correct, there is no
guarantee that the data in them is intact.  In addition, the longer the file
was, the less chance there is that it was written to the file system without
appreciable fragmentation (except in special circumstances).
-->
もちろん、ここで仮定したデータブロックのブロック番号が正しいとしても、
その中身であるデータそのものが書き換えられていないという保証はありません。
さらに、ファイルが大きくなればなるほど、そのファイルが(特殊な環境を覗いて)
なんらかのフラグメンテーションを起こさずに、ファイルシステムに書き込まれて
いる可能性は小さくなります。
</para>

<para>
<!--
You should note that I assume throughout that your blocksize is 1024 bytes, as
this is the standard value.  If your blocks are bigger, some of the numbers
above will change.  Specifically: since each block number is 4 bytes long,
blocksize/4 is the number of block numbers that can be stored in each indirect
block.  So every time the number 256 appears in the discussion above, replace
it with blocksize/4.  The `number of blocks required' boundaries will also have
to be changed.
-->
注意してほしいのは、この文書ではこれまでブロックサイズが標準的な 1024 バイトで
あると仮定した上で説明しているということです。ブロックサイズをそれ以上に
設定している場合、上述の数字は変化します。特に、個々のブロック番号は 4 バイト
長なので、"ブロックサイズ/4" は、個々の間接ブロックにあるブロック番号の数と
一致します。それゆえ、上記の説明で 256 という数字が現れたときは、
必ず "ブロックサイズ/4" に置き換えてください。「必要なブロックの数」の境界も
変わることになるはずです。
</para>

<para>
<!--
Let's look at an example of recovering a longer file.
-->
それでは、大きなファイルの復旧例を見てみましょう。
</para>

<para>
<screen>
  debugfs:  stat &#60;1387&#62;
  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
</screen>
</para>

<para>
<!--
There seems to be a reasonable chance that this file is not fragmented:
certainly, the first 12 blocks listed in the inode (which are all data blocks)
are contiguous.  So, we can start by retrieving those blocks:
-->
上記ファイルがフラグメント化していない可能性は、そこそこあるように思われます。
i-node にリストアップされている冒頭の 12 ブロック 
(これらはすべてデータブロックです) は確かに連続しています。
まずこれらのブロックを復旧することから始めましょう。
</para>

<para>
<screen>
  # fsgrab -c 12 -s 8314 /dev/hda5 &#62; /mnt/recovered.001
</screen>
</para>

<para>
<!--
Now, the next block listed in the inode, 8326, is an indirect block, which we
can ignore.  But we trust that it will be followed by 256 data blocks (numbers
8327 through 8582).
-->
ここで、i-node にリストアップされている次のブロック、すなわち 8326 は
間接ブロックなので無視できます。次にこの間接ブロックに続いて 256 個の
データブロックが連続していると信じましょう (8327 番から 8582 番までです)。
</para>

<para>
<screen>
  # fsgrab -c 256 -s 8327 /dev/hda5 &#62;&#62; /mnt/recovered.001
</screen>
</para>

<para>
<!--
The final block listed in the inode is 8583.  Note that we're still looking
good in terms of the file being contiguous: the last data block we wrote out
was number 8582, which is 8327 + 255.  This block 8583 is a doubly indirect
block, which we can ignore.  It is followed by up to 256 repetitions of an
indirect block (which is ignored) followed by 256 data blocks.  So doing the
arithmetic quickly, we issue the following commands.  Notice that we skip the
doubly indirect block 8583, and the indirect block 8584 immediately (we hope)
following it, and start at block 8585 for data.
-->
i-node に表記された最後のブロックは 8583 です。ここでもまた、ファイルの
データブロックが連続しているものとみなします。上記で書き出した
最後のデータブロックは、8327 + 225 = 8582 番でした。次の 8583 ブロックは
二重間接ブロックなので無視できます。そしてこのブロックの後に、
間接ブロック (これは無視) に続く 256 のデータブロックが 256 組続くわけです。
これらをすばやく計算すると、次のコマンドを打つべきだということになります。
二重間接ブロック 8583 と 
(おそらく) そのすぐ後にある間接ブロック 8584 はスキップして、
データブロックである 8585 から始めている点に注意してください。
</para>

<para>
<screen>
  # fsgrab -c 256 -s 8585 /dev/hda5 &#62;&#62; /mnt/recovered.001
  # fsgrab -c 256 -s 8842 /dev/hda5 &#62;&#62; /mnt/recovered.001
  # fsgrab -c 256 -s 9099 /dev/hda5 &#62;&#62; /mnt/recovered.001
  # fsgrab -c 256 -s 9356 /dev/hda5 &#62;&#62; /mnt/recovered.001
  # fsgrab -c 256 -s 9613 /dev/hda5 &#62;&#62; /mnt/recovered.001
  # fsgrab -c 256 -s 9870 /dev/hda5 &#62;&#62; /mnt/recovered.001
</screen>
</para>

<para>
<!--
Adding up, we see that so far we've written 12 + (7 * 256) blocks, which is
1804.  The `stat' results for the inode gave us a `blockcount' of 3616;
unfortunately these blocks are 512 bytes long (as a hangover from UNIX), so we
really want 3616/2 = 1808 blocks of 1024 bytes.  That means we need only four
more blocks.  The last data block written was number 10125.  As we've been
doing so far, we skip an indirect block (number 10126); we can then write those
last four blocks.
-->
上記をまとめると、これまでに 12 + (7 * 256) 個のブロック、すなわち 1804 個の
ブロックを書き出したことになります。i-node を <command>stat</command> 
コマンドで調べた結果は、'<literal>blockcount</literal>' で 3616 個と
表示されていました。残念ながら、この表記でのブロック長は (UNIX での伝統を
引き継いで) 512 バイトで計算されているので、実際は 1024 バイトで計算すると 
3616/2 = 1808 ブロックということになります。つまり、あと 4 ブロック足りない
だけだということです。最後に書き出されたブロックは 10125 番であったので、
再度これまでと同様に、間接ブロック(10126 番)をスキップして、それら最後の 
4 ブロックを書き出します。
</para>

<para>
<screen>
  # fsgrab -c 4 -s 10127 /dev/hda5 &#62;&#62; /mnt/recovered.001
</screen>
</para>

<para>
<!--
Now, with some luck the entire file has been recovered successfully.
-->
以上で、運が良ければ、ファイル全体を復旧することに成功したことになります。
</para>

</sect2>

</sect1>

<sect1 id="sec-modify">
<title><!--Modifying inodes directly-->i-node を直接いじる</title>

<para>
<!--
This method is, on the surface, much easier.  However, as mentioned above,
it cannot yet cope with files longer than 12 blocks.
-->
この方法は、表面的には、先ほどよりもずっと簡単です。しかし以前も触れた通り、
12 ブロック以上の大きなファイルに対しては役に立ちません。
</para>

<para>
<!--
For each inode you want to recover, you must set the usage count to one, and
set the deletion time to zero.  This is done with the <literal>mi</literal> 
(modify inode) command in <literal>debugfs</literal>.  Some sample output, 
modifying inode 148003 from above:
-->
復旧したいファイルそれぞれに対して、usage count を 1 に設定し、deletion 
time を 0 に設定します。これには <command>debugfs</command> の <command>
mi</command> (modify i-node) コマンドを使います。例として、これまでと同じく、
i-node 148003 を使って、i-node の変更処理を説明します。
</para>

<para>
<screen>
  debugfs:  mi &#60;148003&#62;
                            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]
</screen>
</para>

<para>
<!--
That is, I set the deletion time to 0 and the link count to 1 and just pressed
return for each of the other fields.  Granted, this is a little unwieldy if you
have a lot of files to recover, but I think you can cope.  If you'd wanted
chrome, you'd have used a graphical `operating system' with a pretty `Recycle
Bin'.
-->
上記で、著者は deletion time に 0 を、link count に 1 を設定し、それ以外
のフィールドではそのままリターンキーを押しました。復旧したいファイル
がたくさんある場合、この方法は確かにちょっと面倒ではありますが、
まあなんとかなると思います。
こうした方法を野暮だと思うのなら、かわいい
「ゴミ箱」アイコン付きのグラフィカルな "オペレーティングシステム" の方を
とっくに使っているはずでしょうから。
</para>

<para>
<!--
By the way: the <literal>mi</literal> output refers to a `Creation time' field 
in the inode.  This is a lie!  (Or misleading, anyway.)  The fact of the 
matter is that you cannot tell on a UNIX file system when a file was created.  
The <literal>st&lowbar;ctime</literal> member of a <literal>struct stat
</literal> refers to the `inode change time', that is, the last time when any 
inode details were changed.  Here endeth today's lesson.
-->
ところで、<command>mi</command> コマンドの出力には、Creation time という
フィールドがあります。これはウソです! (少なくとも誤解の素です。) 
実際には、UNIX ファイルシステムではファイルの
作成時を知ることはできません。構造体 <literal>stat</literal> のメンバ
である <literal>st&lowbar;ctime</literal> は、i-node の更新時間を示す
ものです。つまり i-node 内の何らかの情報が最後に変更された時刻を示している
わけです。と、まあ、この話はここまで。
</para>

<para>
<!--
Note that more recent versions of <literal>debugfs</literal> than the one I'm 
using probably do not include some of the fields in the listing above 
(specifically, <literal>Reserved1</literal> and (some of?) the fragment 
fields).
-->
著者が上記の例で使った <command>debugfs</command> よりも新しいバージョン
を使う場合は、例題で示したフィールドのいくつかが省略されるかもしれない
ので注意してください(特に、<literal>Reserved1</literal> と fragment フィールド
(のいくつか) は省略されるようです)。
</para>

<para>
<!--
Once you've modified the inodes, you can quit <literal>debugfs</literal> and 
say:
-->
i-node の変更が済んだら、<command>debugfs</command> を終了して、以下のように
してください。
</para>

<para>
<screen>
  # e2fsck -f /dev/hda5
</screen>
</para>

<para>
<!--
The idea is that each of the deleted files has been literally undeleted, but
none of them appear in any directory entries.  The <literal>e2fsck</literal> 
program can detect this, and will add a directory entry for each file in the
<literal>/lost+found</literal> directory of the file system.  (So if the 
partition is normally mounted on <literal>/usr</literal>, the files will now 
appear in <literal>/usr/lost+found</literal> when you next mount it.)  All 
that still remains to be done is to work out the name of each file from its 
contents, and return it to its correct place in the file system tree.
-->
これには次のような意味があります。すなわち、削除されていたおのおのファイル
は既に文字通り復旧しているのですが、まだディレクトリエントリには表示されない
状態です。<command>e2fsck</command> プログラムはこの状態を検出して、
そのファイルシステムの <filename>/lost+found</filename> ディレクトリ内に
個々のファイルのディレクトリエントリを追加するようになっています。
(したがってパーティションが通常 <filename>/usr</filename> にマウント
されるのだとすると、ファイルシステムが次にマウントされた際に、復旧ファイルは 
<filename>/usr/lost+found</filename> に現れるわけです。) ここまで来れば、
あとはそのファイルの中身からファイル名を割り出して、そのファイルを
ファイルシステムツリーの適切な場所に戻すだけです。
</para>

<para>
<!--
When you run <literal>e2fsck</literal>, you will get some informative output, 
and some questions about what damage to repair.  Answer `yes' to everything 
that refers to `summary information' or to the inodes you've changed.  
Anything else I leave up to you, although it's usually a good idea to say 
`yes' to all the questions.  When <literal>e2fsck</literal> finishes, you can 
remount the file system.
-->
<command>e2fsck</command> を実行した際には、各種情報が出力されると同時に、
どのダメージを修復すべきかの質問が表示されます。"summary information" 
もしくは変更した i-node に関する事柄が表示された場合は、すべて yes で
答えてください。それ以外の質問については読者の判断にお任せしますが、
通常はすべての質問に yes で答えておくほうが無難です。<command>e2fsck</command>
 コマンドが終了したら、ファイルシステムを再マウントできます。
</para>

<para>
<!--
Actually, there's an alternative to having <literal>e2fsck</literal> leave the 
files in <literal>/lost+found</literal>: you can use <literal>debugfs
</literal> to create a link in the file system to the inode.  Use the 
<literal>link</literal> command in <literal>debugfs</literal> after
you've modified the inode:
-->
実は、<command>e2fsck</command> を使ってファイルを <filename>/lost+found
</filename> に出現させる以外の方法もあります。<command>debugfs
</command> を使えば、そのノードに対するリンクをファイルシステム内に
作成できるのです。i-node を変更した後で <command>debugfs</command> 
作成することが可能です。i-node を変更した後で、<command>debugfs</command> 
の <command>link</command> コマンドを使います。
</para>

<para>
<screen>
  debugfs:  link &#60;148003&#62; foo.txt
</screen>
</para>

<para>
<!--
This creates a file called <literal>foo.txt</literal> in what <literal>debugfs
</literal> thinks is the current directory; <literal>foo.txt</literal> will be 
your file.  You'll still need to run <literal>e2fsck</literal> to fix the 
summary information and block counts and so on.
-->
これによって、<command>debugfs</command> コマンドが正しいと判断した
ディレクトリ内に <filename>foo.txt</filename> という名前のファイルが
作成されます。この <filename>foo.txt</filename> というファイルが、読者の
求めていたファイルとなるはずです。ただこの場合でも、<command>e2fsck</command>
 を使って、summary 情報や block count 等を修復する必要があります。
</para>

</sect1>

<sect1 id="sec-easier">
<title><!--Will this get easier in future?-->
将来的にはもっと簡単になるでしょうか？</title>

<para>
<!--
Yes.  In fact, I believe it already has.  Although as of this writing,
current stable kernels (in the 2.0.x series) zero indirect blocks, this does
not apply to development kernels in the 2.1.x series, nor to the stable
2.2.x series.  As I write this on 2 February 1999, kernel 2.2.1 was released
a few days ago; Linux vendors are likely to start producing distributions
containing and supporting 2.2.x kernels a month or two from now.
-->
なります。事実、既にそうなってきていると著者は考えています。ただ、先ほど
説明したように、現在の安定版カーネル (2.0.x シリーズ) では、i-node の
間接ブロック番号はファイルの削除時にゼロに戻されてしまいます。しかしこれは 
2.1.x シリーズの開発版カーネルと 2.2.x の安定版カーネルには当てはまりません。
今これを書いている日時が 1999年2月2日なのですが、数日前にカーネル 2.2.1 が
リリースされたところです。1, 2 カ月すれば、Linux ベンダーは 2.2.x カーネルを
使ったディストリビューションを作りはじめるでしょう。
</para>

<para>
<!--
Once the indirect-zeroing limitation has been overcome in the production
kernels, a lot of my objections to the technique of modifying inodes by hand
will disappear.  At the same time, it will also become possible to use the
<literal>dump</literal> command in <literal>debugfs</literal> on long files, 
and to conveniently use other undeletion tools.
-->
安定版カーネルで間接ブロックに伴う困難が克服されれば、著者が手動で i-node 
をいじることに反対していた論拠の多くも消失します。同時に、<command>debugfs
</command> 付属の <command>dump</command> コマンドを大きなファイルに対して
使用したり、もっと簡単な他の復旧ツールを使うといったことが可能になる
でしょう。
</para>

</sect1>

<sect1 id="automation">
<title><!--Are there any tools to automate this process?-->
一連のプロセスを自動化するツールはないですか？</title>

<para>
<!--
As it happens, there are.  Unfortunately, I believe that they currently
suffer from the same problem as the manual inode modification technique:
indirect blocks are unrecoverable.  However, given the likelihood that this
will shortly no longer be a problem, it's well worth looking these programs
out now.
-->
あることはあります。ただ残念ながらそれらには、手動で i-node をいじる場合と
同じ問題があります。つまり、間接ブロックのデータを復旧できなないのです。
しかし前述したように、これは遠からず問題にならなくなるかもしれないので、
ここでそうしたプログラムをざっと眺めてみる価値はあります。
</para>

<para>
<!--
I have written a tool called <literal>e2recover</literal>, which is 
essentially a Perl wrapper around <literal>fsgrab</literal>.  It makes a 
reasonable amount of effort to deal with zeroed indirect blocks, and seems to 
work fairly well as long as there
was no fragmentation.  It also correctly sets the permissions (and when
possible the ownership) of recovered files, and even makes sure that
recovered files have the correct length.
-->
著者は、<filename>e2recover</filename> というツールを作成しました。これは 
Perl で書かれた、実質的には <command>fsgrab</command> のラッパーです。
間接ブロックのブロック番号がゼロにされてしまった場合でもファイルを取り扱える
よう工夫をこらしてあり、フラグメンテーションさえなければ、非常によい
結果をもたらすと思います。また復旧したファイルのパーミッション (および可能
ならファイル所有者についても) を正しく設定し、復旧されたファイルが
元のファイルサイズと一致しているか否かも確認します。
</para>

<para>
<!--
I originally wrote <literal>e2recover</literal> for the forthcoming major 
update to this Howto; unfortunately this means that much of the useful 
documentation for <literal>e2recover</literal> is scheduled for inclusion in 
that update.  Be that as it may, it should be useful now; it can be downloaded 
from <ulink url="http://pobox.com/~aaronc/tech/e2-undel/">my web site</ulink>, 
and soon from Metalab.
-->
<filename>e2recover</filename> は、来るべきこの文書の改訂版のために
作成されました。つまり今のところ、<filename>e2recover</filename> 
用の詳しい解説は、この文書の次回の改訂の際に記載するめどしか立っていない
ということです。ただ、それはそれとして、現状でも <filename>e2recover
</filename> は役に立つはずです。ダウンロードする場合は <ulink 
url="http://pobox.com/~aaronc/tech/e2-undel/">著者のウェブサイト</ulink>
をお使いください。近いうちに Metalab からもダウンロードできるようになる
と思います。
</para>

<para>
<!--
Scott D. Heavner is the author of <literal>lde</literal>, the Linux Disk 
Editor.  It can be used as both a binary disk editor, and as an equivalent to 
<literal>debugfs</literal> for ext2 and minix file systems, and even for xia 
file systems (though xia support is no longer available in 2.1.x and 2.2.x 
kernels).  It has some features for assisting undeletion, both by walking the 
block list for a file, and by grepping through disk contents.  It also has 
some fairly useful documentation on basic file system concepts, as well as a 
document on how to use it for undeletion.  Version 2.4 of <literal>lde
</literal> is available on <ulink
url="http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz">
Metalab</ulink> and mirrors, or on <ulink
url="http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html">
the author's web site</ulink>.
-->
Scott D. Heavner は、<filename>lde</filename>、すなわち the Linux Disk 
Editor の作者です。これは、バイナリディスクエディタであると同時に、
<command>debugfs</command> の代替ツールとして ext2 と minix ファイル
システム、および xia ファイルシステムを扱うことができます (ただし 
2.1.x や 2.2.x カーネルでは xia のサポートは打ち切られています)。
そして、ファイルの一連のブロックを辿ったり、ディスク情報を検索したり
して、ファイルの復旧作業を手助けする機能も付いています。また、ファイル
システムの基本的な概念を述べた良質の文書と、復旧の際のツールの使い方を
述べた分かり易い文書とが添付されています。<filename>lde</filename> の
バージョン 2.4 は、<ulink
url="http://metalab.unc.edu/pub/Linux/system/filesystems/lde-2.4.tar.gz">
Metalab</ulink> やそのミラーサイト、および <ulink
url="http://www.geocities.com/CapeCanaveral/Lab/7731/lde.html">
作成者のウェブサイト</ulink> から入手できます。
</para>

<para>
<![IGNORE[
Another possibility is offered by the GNU Midnight Commander, <literal>mc
</literal>.  This is a full-screen file management tool, based AFAIK on a 
certain MS-DOS program commonly known as `NC'.  <literal>mc</literal> supports 
the mouse on the Linux console and in an xterm, and provides virtual file 
systems which allow tricks like <literal>cd</literal>-ing to a tarfile.  Among 
its virtual file systems is one for ext2 undeletion.  It all sounds very handy,
 although I must admit I don't use the program myself -- I prefer good 
old-fashioned shell commands.
]]>
もうひとつの方法として、GNU Midnight Commander, <filename>mc</filename> が
あります。これはフルスクリーンのファイル管理ツールであり、著者の知る限り、
'NC' と呼ばれていた MS-DOS プログラムがベースになっています。<filename>
mc</filename> は、Linux コンソールや xterm 上でのマウス操作をサポートし、
さらに仮想ファイルシステムを提供することで、tar ファイル内にディレクトリ
を移動するといったトリックも可能になっています。その仮想ファイルシステム
の機能のひとつとして、ext2 でのファイルの復旧があります。使いやすさは
抜群です。ただ、実際のところ、著者自身は使ってはいません。古き良きのシェル
コマンド方式のほうが好きだからです。
</para>

<para>
<![IGNORE[
To use the undeletion feature, you have to configure the program with the
<literal>-</literal><literal>-with-ext2undel</literal> option; you'll also 
need the development libraries and include files that come with the <literal>
e2fsprogs</literal> package.  The version provided in <ulink
url="http://www.debian.org/">Debian GNU/Linux</ulink> is
built in this way; the same may apply to packages for other Linux
distributions.  Once the program is built, you can tell it to <literal>cd
undel:/dev/hda5</literal>, and get a `directory listing' of deleted files.  
Like many current undeletion tools, it handles zeroed indirect blocks poorly --
it typically just recovers the first 12k of long files.
]]>
復旧機能を使うには、プログラムを <option>--with-ext2undel</option> 
オプションを付けて configure を実行する必要があります。また <filename>
e2fsprogs</filename> に付属する開発用ライブラリとインクルードファイルも
必要になります。<ulink url="http://www.debian.org/">Debian GNU/Linux
</ulink> に同梱されている <filename>mc</filename> は、予めこのオプション付きで
ビルドされています。他のディストリビューションでもおそらく同じだと
思われます。プログラムのビルドが済んだら、<filename>mc</filename> に 
<command>cd undel:/dev/hda5</command> と命令して、削除ファイルの一覧を
見ることができます。今日の多くの復旧ツール同様、<filename>mc</filename> 
もゼロ埋めされた間接ブロックを上手く扱えません。一般に、大きなファイル
の冒頭 12k だけしか復旧できないこともあります。
</para>

<para>
<!--
The current version may be downloaded from
<ulink url="ftp://ftp.nuclecu.unam.mx/Midnight/devel/">
the Midnight Commander ftp site</ulink>.
-->
最新バージョンは、<ulink url="ftp://ftp.nuclecu.unam.mx/Midnight/devel/">
the Midnight Commander の ftp サイト</ulink>からダウンロードできます。
</para>

</sect1>

<sect1 id="colophon">
<title><!--Colophon-->あとがき</title>

<para>
<!--
I intend to produce regular updates to this document as long as I have
both enough time to do it, and something interesting to say.  This means
that I am eager to hear comments from readers.  Could my writing be clearer?
Can you think of something that would make matters easier?  Is there some
new tool that does it all automatically?  Whatever.  If you have something
to say about this document or about the <literal>fsgrab</literal> or <literal>
e2recover</literal> tools, drop me a line on <literal><ulink
url="mailto:aaronc@pobox.com">aaronc@pobox.com</ulink></literal>.
-->
書くための時間と、それに値するトピックがある限り、この文書を定期的に更新
していきたいと思っています。つまり、著者は読者からのコメントを切望して
います。文章がもっと分かり易くならないか、より簡単に解決する方法はないか、
自動処理をする新しいツールが出ていないか等々、この文書や <filename>fsgrab
</filename>、<filename>e2recover</filename> ツールに関する話題があれば、
是非 &lt;aaronc@pobox.com&gt; までメールをお送りください。
</para>

</sect1>

<sect1 id="sec-credits">
<title><!--Credits and Bibliography-->
Credit と参考文献</title>

<para>
<!--
<QUOTE>
`If I have seen farther than others, it is because I was standing on
the shoulders of giants.' (Isaac Newton)</QUOTE>
-->
<blockquote><attribution>Isaac Newton</attribution>
<para>
もし私が他人よりも遠くを見ているとするなら、それは、私が巨人たちの
肩の上に立っているからだ。
</para>
</blockquote>
</para>

<para>
<!--
This mini-Howto was originally derived from a posting in the
<literal><ulink url="news:comp.os.linux.misc">comp.os.linux.misc</ulink>
</literal> newsgroup by Robin Glover <literal><ulink 
url="mailto:swrglovr@met.rdg.ac.uk">swrglovr@met.rdg.ac.uk</ulink></literal>.
I would like to thank Robin for graciously allowing me to rework his ideas into
this mini-Howto.
-->
この mini-HOWTO は、Robin Glover &lt;swrglovr@met.rdg.ac.uk&lt; が 
comp.os.linux.misc に投稿した記事を元にしています。彼のアイデアをもとに
この mini-HOWTO を作ることを許可してくれた Robin に感謝します。
</para>

<para>
<!--
I would also like to take this opportunity to thank once again all the
people who've written to me about the Howto.  Receiving grateful comments
makes the effort worth while.
-->
またここで、本書について著者にメールを送ってくれたすべての人にも、
もう一度感謝します。励ましのコメントをいただいて、報われる
思いです。
</para>

<para>
<!--
Some bibliographic references:
-->
以下に、参考文献をいくつか紹介します。
</para>

<para>

<itemizedlist>
<listitem>

<para>
<![IGNORE[
<literal>Frisch</literal>, Aeleen (1995), <emphasis>Essential System 
Administration</emphasis>, second edition, O'Reilly and Associates, Inc., 
ISBN: 1-56592-127-5.
]]>
<literal>Frisch</literal>, Aelenn (1995), <emphasis>Essential System 
Administration</emphasis>, second edition, O'Reilly and Associates, Inc..
ISBN: 1-56592-127-5
</para>
</listitem>
<listitem>

<para>
<literal>Garfinkel</literal>, Simson, Daniel <literal>Weise</literal> and 
Steven <literal>Strassmann</literal> (1994), <emphasis>The Unix-Haters 
Handbook</emphasis>, IDG Books, ISBN: 1-56884-203-1.  

<!--
Much of this book is merely the adolescent whinings of people who think that
<emphasis>their</emphasis> operating system was so much better than Unix, and 
much of the rest simply doesn't apply if you have a well-written user-space 
such as GNU. But there is some wheat among the chaff; for example, the 
discussion of how easy it is to delete files under Unix is well worth reading.
-->
この文書の大半は、「自分たち」のオペレーティングシステムが Unix よりも
ずっと優れている考える人たちによる、子供じみたたわごとにすぎず、残りの大半も、
GNU のような出来のいいユーザ空間を持っている場合には全く当てはまらないこと
ばかりです。とはいえ、くだらない記述の中にも、光るものがないわけでは
ありません。例えば、Unix 上でのファイルの削除がどれほど安易に行われ得るか
についての議論は、読むに値します。
</para>
</listitem>
<listitem>

<para>
<literal>Glover</literal>, Robin (31 Jan 1996), <emphasis>HOW-TO : undelete 
linux files (ext2fs/debugfs)</emphasis>, comp.os.linux.misc Usenet posting.

</para>
</listitem>
<listitem>

<para>
<literal>Peek</literal>, Jerry, Tim <literal>O'Reilly</literal>, Mike 
<literal>Loukides</literal> et al (1993), <emphasis>UNIX Power Tools
</emphasis>, O'Reilly and Associates, Inc./Random House, Inc., ISBN:
0-679-79073-X.  Second edition, 1998.
</para>
</listitem>

</itemizedlist>

</para>

</sect1>

<sect1 id="legalities">
<title><!--Legalities-->法的な事柄</title>

<para>
<!--
All trademarks are the property of their respective owners.  Specifically:
-->
商標はすべて、それぞれの所有者がその権利を保持しています。特に、
</para>

<para>

<itemizedlist>
<listitem>

<para>
<!--
<emphasis>MS-DOS</emphasis> and <emphasis>Windows</emphasis> are trademarks of
<ulink url="http://www.microsoft.com/">Microsoft</ulink>.
-->
MS-DOS と Windows は、<ulink url="http://www.microsoft.com/">Microsoft
</ulink> の商標です。
</para>
</listitem>
<listitem>

<para>
<!--
<emphasis>UNIX</emphasis> is a trademark of <ulink
url="http://www.opengroup.org/">the Open Group</ulink>.
-->
UNIX は、<ulink url="http://www.opengroup.org/">the Open Group</ulink> 
の商標です。
</para>
</listitem>
<listitem>

<para>
<!--
<emphasis>Linux</emphasis> is a trademark of Linus Torvalds in the USA and 
some other countries.
-->
Linux は、USA その他の国における Linus Torvalds の商標です。
</para>
</listitem>

</itemizedlist>

</para>

<para>
<!--
This document is Copyright (c) 1997, 1999 Aaron Crane
<literal><ulink url="mailto:aaronc@pobox.com">aaronc@pobox.com</ulink>
</literal>.
It may be freely redistributed in its entirety, including the whole of this
copyright notice, but may not be changed without permission from either the
author or the Linux Documentation Project HOWTO Coordinator.  Dispensation
is granted for copying small verbatim portions for the purposes of reviews
or for quoting; in these circumstances, sections may be reproduced in the
presence of an appropriate citation but without this copyright notice.
-->
この文書は、Copyright (c) 1997, 1999 Aaron Crane &lt;aaronc@pobox.com&gt; 
が著作権を保持しています。この文書の頒布については、この著作権表示自体を
含めた全文全体として、自由に頒布することを許可します。しかし、文書の改変は、
著者もしくは Linux Documentation Project の HOWTO コーディネータの許諾が
ない限り行わないでください。批評や引用目的で、この文書の僅かな部分を逐語
的に複製することは認められています。その場合、文書の複製に際し、引用元を適切に
表示するならば、この著作権表示を記載する必要はありません。
</para>

<para>
<!--
The author requests but does not require that parties intending to sell copies
of this document, whether on computer-readable or human-readable media, inform
either him or the Linux HOWTO Coordinator of their intentions.
-->
この文書をコンピュータ用の媒体もしくは印刷媒体で販売しようとする場合、
著者自身か Linux HOWTO コーディネータにその計画を事前に知らせてくれるよう
希望します。ただ、これはあくまで希望です。
</para>

<para>
<!--
The Linux HOWTO Coordinator is currently Tim Bynum
<literal><ulink url="mailto:linux-howto@metalab.unc.edu">
linux-howto@metalab.unc.edu</ulink></literal>.
-->
現在の Linux HOWTO コーディネータは、Tim Bynum &lt;
linux-howto@metalab.unc.edu&gt; です。
</para>

</sect1>

<sect1 id="jftrans">
<title>日本語訳について</title>
<para>
誤字・脱字・誤訳等は &lt;JF@linux.or.jp&gt; までお知らせください。
</para>
<para>
<simplelist columns="2" type="horiz">
<member>翻訳：</member>
<member>吉川雅英 &lt;kikkawa@m.u-tokyo.ac.jp&gt; (1997/10/16)</member>
<member>校正：</member>
<member>中野武雄</member>
<member></member>
<member>菊谷誠</member>
<member>更新：</member>
<member>千旦裕司 &lt;ysenda@pop01.odn.ne.jp&gt; (2001/09/11)</member>
<member>校正：</member>
<member>中野武雄 &lt;nakano@apm.seikei.ac.jp&gt;</member>
</simplelist>
</para>
</sect1>

</article>
