Restoring via inode that's no longer in the journal?

Question

I had a folder deleted from a SMB share from a windows machine. Thanks to zero confirmation a whole folder was deleted. First ran photorec that pulled most of the files except 1, the very last file copied. Further testing with extundelete was able to pull the whole folder minus 4-5 files. However the single most important file again was not recovered. Looking at the inodes I can see the files recovered have sequential inodes. So i was able to narrow down the exact inode. However I get the following trying to recover that specific 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.

However when I search for that inode I do get data:

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

Using debugfs I tried to dump the inode however all I got was a file the correct size but zero'd.

The size in bytes, dates, I am 99% sure this is the exact inode file I need. Is this data basically a stub missing a pointer to the exact locations on the disk? Is there anyway to use this inode data to recover the actual data?

Answer 1

See https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Contents_of_inode.i_block

The "File flags: 524288" is 0x80000 in hex, so it is the "extents" flag. So, although your extundelete interpreted the inode.i block as direct/indirect/double indirect/triple indirect block pointers, this is not correct. But we can still decode this ourselves.

The first number in "Direct blocks" field is 62218, which is 0xF30A in hex - the magic number for the extent tree mode (eh_magic), confirming the "File flags" value. Since the old-style block pointers are little-endian 32-bit, but the extent mode magic number is 16-bit, we know that the eh_entries field would have been displayed as part of the first "Direct blocks" number. Since it did not mess up the displayed magic number, eh_entries must be zero.

Likewise, the second number in "Direct blocks" is 4, which decodes to two 16-bit numbers: 4 for eh_max and 0 for eh_depth. The rest of the inode.i block seem to be all zeroes.

So here are the contents of the inode.i block interpreted according to extent mode:

• eh_magic = 62218, correct.
• eh_entries = 0, no valid entries following the header.
• eh_max = 4, maximum of 4 entries in inode.i.
• eh_depth = 0, this extent node would point directly to data blocks
• eh_generation = 0 (not used by standard ext4)

The rest of the inode.i is all zeroes, so there are no valid struct ext4_extent nor struct ext4_extent_idx nodes here, confirming the eh_entries value of 0.

So unfortunately it looks like the extent table has been zeroed out as part of the delete operation, and the actual pointers indicating the location of the file's blocks on disk are gone. So you're correct, this is indeed just a stub.