Curt Sampson sez:
/*
 * 
 * Actually, one of my main complaitnts about dump is there doesn't
 * appear to be a way to verify the integrity of a dump, and it doesn't
 * even appear to do checksums on the files. That's why I've been
 * using Gnu cpio with the -H crc option for so long. (It's still
 * irritating that it doesn't check the crc when it lists, though;
 * you have to do an actual extract to do that.)
 * 
 * Personally, I'd switch to dump in a flash if a) it did a checksum
 * or CRC of each file, and stored it in the dump file, and b) it
 * checked this and generated a message on mismatch when you did a
 * restore -t.

The problem with that, and this is actually one of dump's major
selling points, is that dump prepends a table of contents to the
beginning of the dump.  This is what allows an interactive selective
restoral of files, as well as allowing a quick listing without having
to go through the ENTIRE N-volume set of tapes, each of which could
take an hour to go through.

I'd like to see someone else come up with a non-proprietary
format which can do things with as much integrity as dump while
maintaining its throughput.  To wit:

	* Any program doing a file tree walk is going to be slow;
	  backing up by inode from the raw disk is significantly
	  faster.

	* Any program which fails to put the header at the beginning
	  of the tape is going to run into performance problems during
	  a listing of the Table of Contents.

[And, silly me, here I am trying to write a tar-compatible program which
 will do ftw*() and put a table of contents at the front for interactive
 extraction.  Anyone who says that interactive restoral is merely icing
 on the cake has never had to do a sparse restoral very often.]

 */





				--*greywolf;
--
Rule #1 of Role Playing Gaming:
	Never give the Gamemaster ideas.