通常、エディターはファイルを保存するときに、削除するか0に切り捨てて、割り当てられたスペースを解放してから書き込み、新しいスペースを割り当てます。これにより、ファイルシステムはデータを完全に異なる物理的な場所に配置します。したがって、あなたのアイデアはうまくいかないかもしれません。
filefrag
またはを使用してファイルの物理的な場所を取得し、その物理的な場所を直接読み取るhdparm --fibmap
ために使用dd
できます。ここで別のコンテキストでこのプロセスを説明しました:https : //unix.stackexchange.com/a/85880/30851
あなたの場合、テキストデータを見つけるための一般的なアプローチが必要になる可能性が高くなります...
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings
連続したASCIIデータを検索し(他のエンコーディングもサポートしますが、UTF-8については不明です。コードまたは英語の場合は必要ありません)、見つかったオフセットも出力します。
text snippet
探しているファイルの一部にあることを覚えている、正確で一意のテキストサンプルでなければなりません(1行で)。(正確にわからない場合は、代わりに正規表現でgrepを実行できます。)
-n 12
strings
探す最小の長さです。12
の長さである必要がありますtext snippet
。このパラメーターはオプションですが、提供されている場合はstrings | grep
、少し速くするのに役立ちます。
パーティション全体を読み込むには長い時間がかかりますが、成功した場合dd
は、一般的な領域を取得し、属していないものを削除するためにフィードできるオフセットがあります。
私はそのディレクトリで何もしていません
ディレクトリがマウントポイントにならない場合...ほとんどのファイルシステムは「ディレクトリごとに」スペースを実際に予約しないので...ファイルシステム全体のすべての書き込みが探しているビットを上書きする可能性があります。データ回復の状況では、通常、すべてを読み取り専用モードに切り替えます。
strings
、非常に幸運でない限り、ファイルの一部のみを検索します。