Re: [Extundelete-users] Could not find correct inode number past inode <number>

[<ext...@li...>]

Dear Nic, dear list,


first of all: Thanks for your answer!

I tried foremost (using the following line:
    NONE    y    48    02184f2a28d2cfd6    
) with 02184f2a28d2cfd6 being the string the file should start with,
and I tried magicrescue but could not find the required file. I also tried to find it using grep, which used to break after some time, prompting: "Cannot allocate memory". Probably it got a line, which was too long for it.

I ran extundelete with the --restore-all option, which recovered a number of my lost data - just the keyfile is still missing to unencrypt them... I also used "grep" and "find" (the required file has a fixed size) to look for it in the lost+found (and the RECOVERED_FILES) folder, unfortunately without a positive result.

> Also, before giving up, you may want to run extundelete with
> the option "--inode 16386" and again with the option "--restore-inode 16386", as the output of those commands may provide some useful information.

I tried it, and I got some output, which just is not very useful for me, for I'm no filesystem's expert and thus am lacking the qualification to interpret the results. I dare to post them here, in case you (or anybody else in the list) could take a short look at it:

ubuntu@ubuntu:~$ sudo extundelete --inode 16386 /dev/sda7
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 2459 groups loaded.
Contents of inode 16386:
0000 | c0 41 e8 03 00 00 00 00 55 9a 38 4c 55 9a 38 4c | .A......U.8LU.8L
[and so on, 16 lines in total]
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Inode is Unallocated
Group: 2
File mode: 16832
Low 16 bits of Owner Uid: 1000
Size in bytes: 0
Access time: 1278777941
Creation time: 1278777941
Modification time: 1278777941
Deletion Time: 1278777941
Low 16 bits of Group Id: 1000
Links count: 0
Blocks count: 0
File flags: 524288
File version (for NFS): 3910567706
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


ubuntu@ubuntu:~$ sudo extundelete --restore-inode 16386 /dev/sda7
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 2459 groups loaded.
Loading journal descriptors ... 30421 descriptors loaded.
Unable to restore inode 16386 (file.16386): Space has been reallocated.

I interpret it as: I can't restore the file, because the data got overwritten. Right? Keep in mind, that I try to restore the inode, not because extundelete found my file at this inode, but because it prompted:
"Could not find correct inode number past inode 16386", which sounds to me like: All inode numbers higher than 16386 cannot be found - and the one you're looking for would be in that area. Do I interpret this correctly? If not, what does it mean? If yes, it's possible, that the leftovers of my file are not at inode number 16386, but lie somewhere else, right?

On the other hand, when I try to restore the whole directory the file was in, I get the following:

ubuntu@ubuntu:~$ sudo extundelete --restore-directory home/.ecryptfs/user/.ecryptfs /dev/sda7
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 2459 groups loaded.
Loading journal descriptors ... 30421 descriptors loaded.
Failed to restore file home/.ecryptfs/ct/.ecryptfs
Could not find correct inode number past inode 722.

(By the way, is the command used properly if I want to recover the directory /home/.ecryptfs/user/.ecryptfs on /dev/sda7?)
Does the message mean, that already inode numbers higher than 722 are not restorable?

Continuing with your suggestion (--inode and --restore-inode), I get the following:

ubuntu@ubuntu:~$ sudo extundelete --inode 722 /dev/sda7
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 2459 groups loaded.
Contents of inode 722:
0000 | 80 81 e8 03 38 00 00 00 c5 20 3a 4c dc a1 38 4c | ....8.... :L..8L
[and so on]
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Inode is Allocated
Group: 0
File mode: 33152
Low 16 bits of Owner Uid: 1000
Size in bytes: 56
Access time: 1278877893
Creation time: 1278779868
Modification time: 1278779868
Deletion Time: 0
Low 16 bits of Group Id: 1000
Links count: 1
Blocks count: 8
File flags: 524288
File version (for NFS): 1130830720
File ACL: 0
Directory ACL: 0
Fragment address: 0
Direct blocks: 127754, 4, 0, 0, 1, 51244, 0, 0, 0, 0, 0, 0
Indirect block: 0
Double indirect block: 0
Triple indirect block: 0


ubuntu@ubuntu:~$ sudo extundelete --restore-inode 722 /dev/sda7
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 2459 groups loaded.
Loading journal descriptors ... 30421 descriptors loaded.
Unable to restore inode 722 (file.722): No undeleted copies found in the journal.


As an extundelete layman, all that sounds rather unhopeful. If so, I'll have to accept that my data got lost and have to go on with a some months older backup lacking a number of recent files and changes. I'd be glad, if you could confirm, whether I'm right with my interpretation and conclusion.

Thank you so much - for your programme, your time and support!

Yours,
ubujo
-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl