| commit | 575307cc63d24766ff789262a5cea7b4faf2fa13 | |
| author | Kalpak Shah <kalpak@clusterfs.com> | |
| Mon, 9 Jul 2007 17:05:45 +0000 (9 13:05 -0400) | ||
| committer | Theodore Ts'o <tytso@mit.edu> | |
| Tue, 10 Jul 2007 11:28:35 +0000 (10 07:28 -0400) | ||
| tree | 4d7b60b5f7a1a2656f239e8a06ad72dc9a0e3b59 | treesnapshot (tar.gz zip) |
| parent | 48b0ea41406970c21fadec2ef746968bdfb81e95 | commitdiff |
e2fsck: Fix salvage_directory when the last entry's rec_len is too big
Recently, one of our customers found this message in pass2 of e2fsck
while doing some regression testing:
"Entry '4, 0x695a, 0x81ff, 0x0040, 0x8320, 0xa192, 0x0021' in ??? (136554) has
rec_len of 14200, should be 26908."
Both the displayed rec_len and the "should be" value are bogus. The
reason is that salvage_directory sets a offset beyond blocksize
leading to bogus messages.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Recently, one of our customers found this message in pass2 of e2fsck
while doing some regression testing:
"Entry '4, 0x695a, 0x81ff, 0x0040, 0x8320, 0xa192, 0x0021' in ??? (136554) has
rec_len of 14200, should be 26908."
Both the displayed rec_len and the "should be" value are bogus. The
reason is that salvage_directory sets a offset beyond blocksize
leading to bogus messages.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
| e2fsck/pass2.c | diffblobblamehistory | |
| tests/f_baddir2/expect.1 | [new file with mode: 0644] | blob |
| tests/f_baddir2/expect.2 | [new file with mode: 0644] | blob |
| tests/f_baddir2/image.gz | [new file with mode: 0644] | blob |
| tests/f_baddir2/name | [new file with mode: 0644] | blob |