WindowsコンピュータのSMB共有からフォルダを削除しました。確認ゼロのため、フォルダ全体が削除されました。初めて走る写真撮影最後にコピーしたファイルを除くほとんどのファイルを抽出しました。 1. 追加テスト拡張を削除4〜5個のファイルを除くフォルダ全体をインポートできます。しかし、最も重要なファイルは回復されませんでした。アノードを見ると、回復されたファイルに連続したアノードがあることがわかります。そのため、正確なアノード範囲を狭めることができました。ただし、特定のインデックスノードを復元しようとすると、次のメッセージが表示されます。
Loading filesystem metadata ... 59613 groups loaded.
Loading journal descriptors ... 29932 descriptors loaded.
Unable to restore inode 60596808 (file.60596808): No undeleted copies found in the journal.
しかし、対応するinodeを検索すると、次のようなデータが得られます。
Loading filesystem metadata ... 59613 groups loaded.
Group: 14794
Contents of inode 60596809:
0000 | e4 81 e8 03 dd df b2 1b 43 2d 08 5d 53 2d 08 5d | ........C-.]S-.]
0010 | fd 97 05 5d 53 2d 08 5d e8 03 00 00 00 00 00 00 | ...]S-.]........
0020 | 00 00 08 00 01 00 00 00 0a f3 00 00 04 00 00 00 | ................
0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0060 | 00 00 00 00 70 57 ff 3f 00 00 00 00 00 00 00 00 | ....pW.?........
0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0080 | 20 00 00 00 ec e9 88 2a b0 16 cf 0f 1c 76 bb a2 | ......*.....v..
0090 | 3c 2d 08 5d d4 64 6c a9 00 00 00 00 00 00 00 00 | <-.].dl.........
00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
Inode is Unallocated
File mode: 33252
Low 16 bits of Owner Uid: 1000
Size in bytes: 464707549
Access time: 1560816963
Creation time: 1560816979
Modification time: 1560647677
Deletion Time: 1560816979
Low 16 bits of Group Id: 1000
Links count: 0
Blocks count: 0
File flags: 524288
File version (for NFS): 1073698672
File ACL: 0
Directory ACL: 0
Fragment address: 0
Direct blocks: 62218, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Indirect block: 0
Double indirect block: 0
Triple indirect block: 0
使用デバッグファイル私はinodeをダンプしようとしましたが、私が得たのは正しいサイズですが、ゼロのファイルだけでした。
サイズ（バイト）、日付、これが私が必要とする正確なinodeファイルであると99％確信しています。このデータは基本的にディスク上の正確な位置へのポインタが欠落しているスタブですか？このinodeデータを使用して実際のデータを回復する方法はありますか？
答え1
バラよりhttps://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Contents_of_inode.i_block
「ファイルフラグ：524288」の16進値は0x80000なので、「extents」フラグです。したがって、ブロックを直接/間接/二重間接/三重間接ブロックポインタとしてextundelete解釈しましたが、これは間違っています。inode.iしかし、私たちはまだそれを自分で解読できます。
「ダイレクトブロック」フィールドの最初の数字は62218です。これは0xF30A 16進数です。eh_magicこれは、範囲ツリーモード（）のマジック番号で「ファイルフラグ」の値をチェックします。以前のスタイルのブロックポインタはリトルエンディアン32ビットですが、スコープモードのマジックナンバーは16ビットなので、このフィールドがeh_entries最初の「ダイレクトブロック」番号の一部として表示されることがわかります。表示されたマジックナンバーを傷つけないので、ゼロでなければなりませんeh_entries。
同様に、「ダイレクトブロック」の2番目の数字は4です。これは2つの16ビット数字（0は4、0eh_maxは0）にデコードされますeh_depth。ブロックの残りの部分はinode.iゼロに見えます。
inode.i範囲モードによって解釈されるブロックの内容は次のとおりです。
eh_magic= 62218、そうです。eh_entries= 0、ヘッダーの後に有効なエントリがありません。eh_max= 4、最大4項目inode.i。eh_depth= 0、エクステントノードはデータブロックを直接指します。eh_generation= 0（標準は使用されませんext4）
残りはすべて0なので、ここには有効なノードもinode.iなく、確認値も0です。struct ext4_extentstruct ext4_extent_idxeh_entries
したがって、残念ながら、範囲テーブルは削除操作の一部としてゼロとして消去されたように見え、ディスク上のファイルブロックの位置を示す実際のポインタは消えています。だからあなたは正しいです。これは実際にちょうどスタブです。