UNIX for Advanced & Expert Users

Hi,

I noticed a weird behavior in extundelete way to choose the filename to which it will restore a given inode. Here is an example :

Code:

root@rescue:~# for after in '' 0 740 741 $(date -d 'now - 1 year' +%s); do rm -rf RECOVERED_FILES/; echo -e "$(date -d@$after 2> /dev/null || echo No date)\t$(extundelete --restore-all ${after:+--after $after} --log info /dev/md2 | grep 694)"; done | column -tns$'\t'
No date                       Restored inode 694 to file RECOVERED_FILES/lib/x86_64-linux-gnu/libanl-2.13.so
Thu Jan  1 01:00:00 CET 1970  Restored inode 694 to file RECOVERED_FILES/lib/x86_64-linux-gnu/libanl-2.13.so
Thu Jan  1 01:12:20 CET 1970  Restored inode 694 to file RECOVERED_FILES/lib/x86_64-linux-gnu/libanl-2.13.so
Thu Jan  1 01:12:21 CET 1970  Restored inode 694 to file RECOVERED_FILES/lib/udev/rules.d/60-gnupg.rules
Tue Dec  8 16:22:37 CET 2015  Restored inode 694 to file RECOVERED_FILES/lib/udev/rules.d/60-gnupg.rules

So apparently, the same inode has been used for two different files. Inode 694 was "/lib/x86_64-linux-gnu/libanl-2.13.so" from EPOCH to EPOCH+740 seconds and then it became "/lib/udev/rules.d/60-gnupg.rules" until today. I have no problem with this as in ext filesystems, the same inode can be reused once cleared. If I look at the file content (which is always the same whatever --after option I set), the actual file recovered is "60-gnupg.rules".

My first surprise is that a change on my system could happen on January 1st 1970 at 1:12. The install is at most 4 years old. But lets say the clock wasn't set at install time and the change happened after 12 minutes (I'm UTC+1). So I'm not complaining about it.

What I'm surprised about is that if one doesn't set an appropriate "--after" option, extundelete will recover an inode to it's oldest filename, leading to filesystem inconsistency.

Is this normal behavior?
Is there a workaround to it?

Regards

filesystem inconsistency? Or just the wrong file?

That is totally unhelpful and might lead other people to believe an actual answer was given to the original post.

If a lib file contains text or if a config file is missing then : It will be the wrong file and the filesystem will be inconsistent.

Neither is repeating something helpful. Nor is linking to a generic dictionary when asking about a term which has a specific meaning for filesystems. "Inconsistent" for a file system means crashed or damaged - a filesystem that can't or shouldn't be used without running fsck first.

If extdelete is crashing your filesystem, you've got bigger problems, and the problems may not be related to extundelete itself.

I second corona688's comment. That filetime is very suspect to start with. I believe you have serious filesystem corruption - meaning the metadata for the files has problems.

inodes are one of the primary objects in a filesystem.

Try this:

Code:

$ sudo touch /forcefsck
$ sudo reboot

I am assuming you do not normally run as root, which is a bad practice. You will see what your problems are.