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);