need help with multi-reel cpio

[Griff Smith]

> I prefer Greg's suggestion over Griff's.  There seem to me to be
> two ways to handle magtapes on UNIX:  (a) make them do the right
> thing to fit the generalized idea of "file";  (b) supply special
> magtape-handling bells and whistles.  I've managed in the past
> to make method (a) serve quite well, even for such things as
> ANSI standard magtapes; since I believe in the generalized file
> approach, that's the method I recommend.  Approach (b) is not
> really necessary, in my opinion.  But whatever approach is used,
> it should be done RIGHT, which has not traditionally been the
> case with UNIX magtape drivers.

I can't argue with the notion that it is better to use a "generalized
file" approach".  The problem is that people keep using the raw tape
device while expecting it to behave like a cooked device.  I think the
raw interface to a device should have all the hooks necessary to
control the device.  In the case of a tape, that includes record and
file positioning, as well as hooks to get controller status.  When
control functions only execute implicitly as a result of file
operations, it becomes impossible to do things that don't fit the
generalized file model.  One of the most vexing examples for me
concerns error analysis.  I sometimes get tapes that have mangled
blocks in them;  I need to stop near a bad block and then pull it back
and forth past the read heads a few times until I can decide what's
wrong.  The System V tape drivers insist on skipping to end of file
after the error, which really gets in my way.  When this happens, I
usually mutter a few curses, rip the tape off the 3B20 and take it over
to a TU78 on a VAX running 4.2BSD.

If someone would take the time to define a tape file system using
something similar to the Eighth edition generalized notion of file
systems, I would be delighted.  It won't happen; tapes aren't used much
for anything but file backups and such refinement isn't worth it.
People hardly ever use the "cooked" tape interface, even though it very
nicely hides record positioning and replaces it with "lseek" support.
The cooked interface might be more useful if one could have arbitrary
size fixed-length blocks when using the cooked device, but that's a bit
messy.

I'll be happy to accumulate suggestions for how tapes should really
work and pass a summary on to the UNIX support folks.  I am more
interested in getting better standards than in grinding my own ax.
Evidence that more than two or three potential customers really care
would be appreciated; the attitude now is that tape support is low
priority and the current software is "good enough".
-- 

Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		(201) 582-7736
Internet:	ggs at ulysses.uucp
UUCP:		ulysses!ggs  ( {allegra|ihnp4}!ulysses!ggs )