tas@mcnc.UUCP (Tim Seaver) (06/23/87)
Subject: The recently posted fix to dumptraverse.c can screw up dump.
Index: etc/dump/dumptraverse.c 4.3BSD
Description:
The recent fix of dumptraverse.c in comp.bugs.4bsd.ucb-fixes
can cause dump to attempt to read one past the maximum inode
in a filesystem. The original 4.3 BSD code looks correct to
me, though there may be a problem elsewhere that caused the
bug originally reported by eplunix!das in <350@eplunix.UUCP>.
(I tried a simple test of dumping and restoring a small filesystem
will all inodes allocated, and the original 4.3 bsd code correctly
dumped and restored the last inode.)
The patch to dumptraverse.c is incorrect because the inode number
is incremented within the loop before reading the inode, so setting
the loop test to '<= maxino' can cause dump to do a getino call
for inode maxino+1, causing an lseek failure and lots of
bread errors from dump.
Repeat-By:
I don't know how to ensure that the bitmap entry for maxino+1
is 1, but it's happened on two different filesystems here.
Fix:
Restore the original 4.3 BSD dumptraverse.c or apply the
fololowing patch to the patched version.
*** dumptraverse.c Tue Jun 23 12:53:03 1987
--- dumptraverse.c.old Fri Jun 19 12:05:28 1987
***************
*** 18,24 ****
ino_t maxino;
maxino = sblock->fs_ipg * sblock->fs_ncg - 1;
! for (ino = 0; ino < maxino; ) {
if ((ino % NBBY) == 0) {
bits = ~0;
if (map != NULL)
--- 18,24 ----
ino_t maxino;
maxino = sblock->fs_ipg * sblock->fs_ncg - 1;
! for (ino = 0; ino <= maxino; ) {
if ((ino % NBBY) == 0) {
bits = ~0;
if (map != NULL)