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>

4 files changed, 20 insertions, 0 deletions

diff --git a/tests/f_baddir2/expect.1 b/tests/f_baddir2/expect.1
new file mode 100644
index 00000000..1bfea69d
--- /dev/null
+++ b/tests/f_baddir2/expect.1
@@ -0,0 +1,12 @@
+Pass 1: Checking inodes, blocks, and sizes
+Pass 2: Checking directory structure
+Directory inode 12, block 0, offset 60: directory corrupted
+Salvage? yes
+
+Pass 3: Checking directory connectivity
+Pass 4: Checking reference counts
+Pass 5: Checking group summary information
+
+test_filesys: ***** FILE SYSTEM WAS MODIFIED *****
+test_filesys: 15/16 files (0.0% non-contiguous), 23/100 blocks
+Exit status is 1
diff --git a/tests/f_baddir2/expect.2 b/tests/f_baddir2/expect.2
new file mode 100644
index 00000000..b85bbabf
--- /dev/null
+++ b/tests/f_baddir2/expect.2
@@ -0,0 +1,7 @@
+Pass 1: Checking inodes, blocks, and sizes
+Pass 2: Checking directory structure
+Pass 3: Checking directory connectivity
+Pass 4: Checking reference counts
+Pass 5: Checking group summary information
+test_filesys: 15/16 files (0.0% non-contiguous), 23/100 blocks
+Exit status is 0
diff --git a/tests/f_baddir2/image.gz b/tests/f_baddir2/image.gz
new file mode 100644
index 00000000..0d9fcdf7
--- /dev/null
+++ b/tests/f_baddir2/image.gz
diff --git a/tests/f_baddir2/name b/tests/f_baddir2/name
new file mode 100644
index 00000000..568a7c96
--- /dev/null
+++ b/tests/f_baddir2/name
@@ -0,0 +1 @@
+salvage last directory entry