Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 v7 ucbopal-1.9 BSD 4.2; site ucbopal.CC.Berkeley.ARPA
Path: utzoo!watmath!clyde!floyd!harpo!decvax!ucbvax!ucbtopaz!ucbopal!dlw
From: dlw@ucbopal.CC.Berkeley.ARPA
Newsgroups: net.bugs.4bsd
Subject: serious bug in dump
Message-ID: <158@ucbopal.CC.Berkeley.ARPA>
Date: Fri, 2-Mar-84 22:00:43 EST
Article-I.D.: ucbopal.158
Posted: Fri Mar  2 22:00:43 1984
Date-Received: Sun, 4-Mar-84 02:24:40 EST
Organization: Univ. of Calif., Berkeley CA USA
Lines: 43

Index:	/usr/src/etc/dump	4.2	Fix

Description:
	There is a serious bug in 4.2 bsd dump/restore. It can
	prevent restore from working even though the tape is "good".
	I posted a full description of this bug under
		Index:	/usr/src/etc/restore
	even though the real bug is in ``dump''. This is because
	it is necessary to fix ``restore'' in order to be able to
	use existing dump tapes.

	The problem is that restore needs the full inode bitmap
	for the filesystem. Dump, as distributed, truncates the
	map to the smallest size possible (the highest inode of
	interest). This causes restore to FAIL in some cases.

Repeat-by:
	newfs /dev/rra0h ra81
	dump 0 /dev/rra0h
	...(add stuff to the filesystem)...
	dump 3 /dev/rra0h

	Now try to restore it.

Fix:
	Below is a diff of dumptraverse.c that will fix the bug.
	The line numbers may not match yours. The routine is
	``bitmap()''.
------
diff  dumptraverse.c.old  dumptraverse.c
------
210,218c211
< 	n = -1;
< 	for (i = 0; i < msiz; i++)
< 		if(map[i])
< 			n = i;
< 	if (n < 0)
< 		return;
< 	n++;
<
< 	spcl.c_count = howmany(n * sizeof(map[0]), TP_BSIZE);
---
> 	spcl.c_count = howmany(msiz * sizeof(map[0]), TP_BSIZE);