Ext3 ファイルシステムで削除したファイルを復元について (2)

grep で削除したファイルの内容が含まれているブロックを探す際に、二つ落し穴があることが分かったので補足しておきます。

[1] ファイルに含まれている先頭の行のキーワードで検索する場合

たとえば、自作の Python スクリプトをうっかり削除してしまったものの、中身について全く記憶がない場合、とりあえず Python スクリプトの先頭ブロックをリストアップしようと、次のようにしたくなるかもしれません。

# grep -a -b '#!/usr/bin/python' /dev/hda1

しかし、たとえばそのファイルのひとつ前のブロックが何か別のファイルの末尾のブロックで次のようなレイアウトになっていたとします。

29fbf90   L   A   R   =   y  \n  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
29fbfa0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
29fc000   #   !   /   u   s   r   /   b   i   n   /   p   y   t   h   o

grep の -b オプションで出力されるオフセットは、マッチしたパターンが含まれている行の先頭の位置です。マッチしたパターンの先頭の文字の位置ではありませんでした。だから grep -b はひとつ前のブロックの改行の次のオフセットを表示してしまいます。

これを避ける簡単な方法をいろいろ考えたのですが、grep の代わりに次のように perl で検索するというのもいいかもしれません。

# perl -n -e 'BEGIN { undef $/; }' -e 'while (m/<パターン>/g) { printf "%d\n", pos(); }'

#!/usr/bin/perl

$block_size = 1024;
$blkno = 0;
open(FH, "< /dev/hda1") or die "can't open $!";
while (read(FH, $block, $block_size)) {
        if ($block =~ m|\#!/usr/bin/python|) {
                print "$blkno\n";
        }
        $blkno += 1;
}

[2] ファイルサイズがブロックサイズより大きくて、キーワードが二つのブロックにまたがっていて、さらにその二つが連続したブロックに割り当てられていなかった場合

これにひっかかるケースはまれかもしれませんので、検索するパターンをちょっと変えれば避けれると思います。