通過不再在日誌中的 inode 恢復？
我從 Windows 機器的 SMB 共享中刪除了一個文件夾。由於零確認，整個文件夾被刪除。首先執行photorec，它提取了除 1 之外的大部分文件，這是最後一個複制的文件。使用extundelete進行的進一步測試能夠將整個文件夾減去 4-5 個文件。然而，一個最重要的文件再次沒有恢復。查看索引節點，我可以看到恢復的文件具有順序索引節點。所以我能夠縮小確切的inode。但是，我得到以下嘗試恢復該特定 inode。
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使用debugfs我試圖轉儲 inode，但我得到的只是一個大小正確但歸零的文件。
以字節、日期為單位的大小，我 99% 確定這是我需要的確切 inode 文件。這些數據基本上是缺少指向磁碟上確切位置的指針的存根嗎？反正有沒有使用這個inode數據來恢復實際數據？
見https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Contents_of_inode.i_block
“文件標誌：524288”是十六進制的 0x80000，所以它是“範圍”標誌。因此，儘管您
extundelete將該塊解釋inode.i為直接/間接/雙重間接/三重間接塊指針，但這是不正確的。但我們仍然可以自己解碼。“直接塊”欄位中的第一個數字是 62218，即十六進制的 0xF30A - 擴展樹模式 (
eh_magic) 的幻數，確認“文件標誌”值。由於舊式塊指針是 little-endian 32 位，但擴展模式幻數是 16 位，我們知道該eh_entries欄位將作為第一個“直接塊”編號的一部分顯示。既然沒有弄亂顯示的幻數，eh_entries就一定是零。同樣，“直接塊”中的第二個數字是 4，它解碼為兩個 16 位數字：4 表示
eh_max，0 表示eh_depth。該inode.i塊的其餘部分似乎全為零。所以這裡是
inode.i根據extent模式解釋的塊的內容：
eh_magic= 62218，正確。eh_entries= 0，標頭後面沒有有效條目。eh_max= 4，最多 4 個條目inode.i。eh_depth= 0，這個extent節點會直接指向數據塊eh_generation= 0（不被標準使用ext4）其餘的
inode.i都是零，所以這裡沒有有效的struct ext4_extentnorstruct ext4_extent_idx節點，確認eh_entries值為0。所以不幸的是，作為刪除操作的一部分，extent table 已經被清零，並且指示文件塊在磁碟上的位置的實際指針已經消失。所以你是對的，這確實只是一個存根。