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.