]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: remove last-entry hack in process_sf_dir2
authorEric Sandeen <sandeen@redhat.com>
Mon, 6 Apr 2015 23:20:15 +0000 (09:20 +1000)
committerDave Chinner <david@fromorbit.com>
Mon, 6 Apr 2015 23:20:15 +0000 (09:20 +1000)
commit38c66abcbc80dbc89470c071eba0c0e87516aa8d
treeb47d6a9ea89b45f7b89ff5c54013080c674af7cb
parent1c934a2590c587707209583d962957bc8645afcb
xfs_repair: remove last-entry hack in process_sf_dir2

process_sf_dir2() tries to special-case the last entry in
a short form dir, and salvage it if the name length is wrong
by using the dir size as a clue to what the length should be.

However, this doesn't actually work; there is either a 32-bit
or 64-bit inode after the name, and with dirv3 there's a file
type in there as well.  Extending the name length to the dir
size means it overlaps these fields, which often have a 0 in
the top bits, and then namecheck() fails the result and junks
it anyway:

> entry #1 is zero length in shortform dir 67, resetting to 29
> entry contains illegal character in shortform dir 67
> junking entry "bbbbbbbbbbbbbbbbbbbbbbbb" in directory inode 67

And depending on the corruption, the current code will set
a new negative namelen if it turns out that the name itself
starts beyond dir size; it can't be shortened enough.

So, we could fix this up, and choose a new namelen such that
the xfs_dir2_ino8_t and/or xfs_dir2_ino8_t and/or file type
still fits at the end, but we really seem to be reaching the
point of diminishing returns.  The chances that nothing but
the name length is wrong, and that the remaining few
bytes at the end of the dir size are actually correct, seems
awfully small.

Therefore just remove this special case, which I think is
of questionable value.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
repair/dir2.c