Path: utzoo!attcan!uunet!nems!mimsy!haven!decuac!shlump.nac.dec.com!shodha.dec.com!alan
From: alan@shodha.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.sys.dec
Subject: Re: Dump program on DS3100
Summary: "Quirk"
Keywords: dump,DS3100
Message-ID: <1328@shodha.dec.com>
Date: 1 Jun 90 21:25:25 GMT
References: <25360@pasteur.Berkeley.EDU>
Distribution: na
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 35

In article <25360@pasteur.Berkeley.EDU>, jac@zabriskie.berkeley.edu (Gordon Jacobs) writes:
} 
} [ Example of using automagick backups... ]
} 
} The program faithfull executes but sometimes the file written 
} has a size that varies drastically from the amount of
} information read.  For example, in the log, the output of dump will be
} 
} DUMP: Estimated 15360 bytes output to file named /dump/tools/tools.lev9.Fri
} DUMP: Dumping (Pass III) [directories]
} DUMP: Dumping (Pass IV) [regular files]
} DUMP: 4461568 bytes were dumped to file /dump/tools/tools.lev9.Fri
} DUMP: Dump is done
} 
} Trying to read the file with restore -if causes a segmentation violation.
} This does not happen all the time, but it will occurr reliably after
} a certain tape dump at a lower level.
} 
} Any ideas what is wrong?

	There is a quirk (bug?) in dump that it writes a fairly
	large dump file when there were no files to be backed
	up.  The size of the file seems to depends on the depth 
	of the directory structure of the file system.  When
	restore sees this (large) empty incremental it dies with
	the segmentation violation mentioned.  I submitted a QAR
	during the V4 field test and was told it would be "Fixed
	in a future release."

} Thanks a lot,
} Gordon Jacobs


-- 
Alan Rollow				alan@nabeth.enet.dec.com