(tar .vs. cpio) : a question

[Guy Harris]

"cpio"s support for multi-volume tapes involves "switching volumes" whenever
a read or write returns an error or returns fewer bytes than were asked to
be read/written.  If the output is a character special file, it asks you to
give the name of a new volume (which would be the same or another tape drive)
and retries the read/write when the user enters it.  If it's not a character
special file, it just reports the error and exits.

Making archiving programs like "tar" or "cpio" check whether something is
a magtape and do special things on a magtape impairs file flexibility not
one whit, any more than a program written to use "termcap" making use of
insert line/delete line characteristics when they exist impairs that
program's ability to use arbitrary terminals, as long as the programs in
question do something correct on non-magtapes/terminals without IL/DL.

If you don't make use of the EOT indication that magtape drives give you
for free, you end up with an abortion like the various UNIX dump/restore
programs' "dead reckoning" method for finding the end of tape (which sucks
because 1) due to write errors being handled with an extended interrecord
gap, the calculation may be wrong and 2) if you put several incremental
dumps on one tape, only the first dump can deal with running out of tape
unless you glop up "dump" by having it output a "tape length used so far"
and accept that length as an argument.

The only real problem is that

	1) not all UNIX systems handle magtapes well; the Berkeley mag
	tape "ioctl"s improve the situation considerably, but they still
	don't do EOT handling perfectly; Alex White's modifications to
	the driver to selectively permit reading/writing past EOT makes
	the EOT feature fully usable (so you can write EOT labels after
	the EOT mark, while still protecting programs that don't know
	that tapes are special from running the tape off the reel).

	2) not all tape drives may permit small amounts of data (like
	trailer labels) to be written past the EOT.

If these facilities were there, "dump" could write its end-of-tape label
when it encounters an EOT, instead of when its count runs out; that would
also mean that if you were "dump"ing to a file it would never think it had
to change tapes.  "tar" and "cpio" have end-of-archive indicators, so
the program wouldn't even have to care about EOT, except to change volumes;
an EOT encountered on an I/O operation would be a indication to tell the
operator to mount a new tape and retry the operation.  Simple, requires little
change to "tar" (none to "cpio", if the code that's there already works) and
permits the program to work perfectly fine on non-tapes.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy