need help with multi-reel cpio

[Griff Smith]

> In article <520 at sdcc13.UUCP> bparent at sdcc13.UUCP (Brian Parent) writes:
> >I'm having trouble with cpio going to multiple reels.  It seems to 
> >write to the additional reels fine, but I have yet to successfully 
> >read the second reel.
> >  ..... [An extended description of the problem.  He's doing it right.]
> 
> Although there are some bugs in cpio having to do with multiple volumes, this
> isn't one of them.  This particular problem happens to be brain damage in the
> way Unix tape drivers work, and is also one of my pet peeves, so excuse me for
> a moment while I dig out my soapbox...

I second the motion.  I have been doing battle inside AT&T for the last
few years; it has had little (probably no) effect.

> The problem is this:  if the tape drive asserts EOT while writing or reading
> a record, the driver returns an error.  That's it; that's the whole problem.

Well, not quite. The earlier Berkeley drivers (and some of the current ones)
ignore the condition and let you pull the tape off the reel.

> ... Note
> that the block is actually written on the tape.  After you have mounted the
> new tape, the block is written \again/ at the beginning of the new reel.

This is a system-dependent bug.  The last time I checked, the VAX version
of System V did it correctly; when the write fails, nothing has been written.
The 3B20 version returns "out of tape" (ENOSPC) after successfully writing
the block that spans the reflective strip.

[deleted long description of industry standards for EOT recognition]

> The mods are simple: when writing a tape, if you get an EOT, backspace the
> record ("unwrite the record"), write a EOF marker (so you can't read it back),
> backspace again (in front of the EOF, so a close (or a shorter write) will
> work as expected), and return an error.

I think this is unnecessarily heroic.  The 4.3BSD TU78 driver simply sets
a flag when a write sets EOT status in the controller.  The next time a
"write" system call is attempted, the driver returns an immediate error.
I think this strategy is also used in the System V VAX tape driver.
If you are paranoid that someone will remove the tape before writing
a tape mark, write it and backspace over it before returning the error
indication.  I prefer having a "write tape mark" ioctl; it will be a no-op
for a non-tape device, so you can still write device independent code.

> On a read that crosses an EOT marker, you do \nothing/.  You've made sure by
> the change above that there should always be an EOF somewhere near the EOT, so
> the logic for EOF will keep you from running off the end of the tape.  And now
> you can read industry-standard multi-reel tapes.......

But you still can't write them.  You have to have some way of overriding
the EOT condition so you can write trailer labels.  The 4.3BSD TU78 driver
implements two ioctls: MTIOCIEOT, which causes EOT errors to be ignored,
and MTIOCEEOT, which causes writes to fail with ENOSPC when writing after
the reflective strip.  You can then write a simple command (or function)
that suppresses the error condition, jams the labels onto the tail of the
tape, then enables EOT recognition again.

> I don't expect that this will ever happen.  Unless some statment specificly
> requiring this is placed in one of the Unix standards (SVID, /usr/group, or
> P1003 (or is it P1006?  Something like that, anyway)), nobody will be motivated
> to actually go to the work of modifying the device drivers to fix this.  And
> Unix will continue to be a ghetto, at least as far as tape compatibility with
> the rest of the world is concerned.......

Amen, brother!

> Are there any standards folks out
> there who will accept this gauntlet and prove me wrong?
> -- 
> -- Greg Noel, NCR Rancho Bernardo    Greg at ncr-sd.UUCP or Greg at nosc.ARPA

And this isn't half of it.  You didn't mention proper error recovery,
informative error codes and program controlled tape positioning operations
(back space record, skip file, back space file, rewind, etc (supported
in Berkeley UNIX!)).
-- 

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