On Sun, 29 Apr 2012 00:26:50 -0700, perryh@plut... wrote:
> Alejandro Imass <ait@p2ee...> wrote:
> > 3) the directories were moved at reboot by journal recovery,
> > fsck or something else
> I think it's *extremely* unlikely that fsck was involved, because
> it just doesn't do things like that.
The point is: fsck moving directories "looks different". In
case inodes get "de-connected" (their reference entries on
level n-1 are gone, their data on level n is still present),
fsck will access the lost+found/ directory in the corresponding
partition's root directory (or create it, if not present) and
write _new_ directory entries with the inode as their name,
because that's the only naming information possible (as the
original names on n-1 aren't accessible anymore). So those
directories will have names like #177628676/ and they _can_
contain subtrees full of data, _including_ names from levels
n+1 and onward. Files also are named #4767667892 and their
names can _maybe_ identified from their content (the "file"
command is helpful, and if they are textfiles containing
a CVS or other revision control system data tag, it's possible
to find out what they've been in their previous life).
However, as it has been explained, fsck will _not_ do so
unless being _allowed explicitely_ to do that kind of
MODIFICATION to the file system. Flags like -yf can do
that, but they are _not_ the default. This is due to the
fact that _any_ critical modification of file systems
requires the _responsible administrator_ to give permission.