need help with multi-reel cpio

[Anton Chernoff]

In article <478 at ncr-sd.UUCP> greg at ncr-sd.UUCP (Greg Noel) writes:
>
>Yes, with the semantics that you get a write error in the EOT region, and the
>record is \not/ \written/.  The only things that you should be permitted to do
>at this point are close, rewind, or possibly issue an ioctl to permit one more
>block to be written.  (And if you do rewind without closing, the driver should
>ensure that EOFs are written.)
>
Sorry, but the standards require that you be able to write past the end of tape
marker.  Remember where and when magtape originated: the makers of Incredibly
Big Machines.  Those systems caused the standards to require that when you
hit EOT, you finish writing the record you were writing (i.e., you write right
over the EOT marker!) and then, as soon as possible, write standard EOT1 labels
and possibly user-defined EOT labels.  The physical standards for tape media
required that there be enough tape past the EOT marker that you could write
a full record (of some fairly large size) plus the required labels.  [Note that
the OS typically handled writing the labels, then prompting the operator to
mount a new reel, and then writing the BOT labels that marked the tape as a
continued reel.]

The EOT mark is ADVISORY ONLY.  It may NOT "prevent" the user from doing
subsequent writes.  The right thing for Unix to do (under control of cpio or
tar) is the SAME THING: finish the write, write an EOT record (OK, a simple EOF
might do, but I don't like the idea), close/rewind the reel, and mount a new
reel.  [cartridge, whatever]  When reading a tape, it is perfectly valid for
the hardware/software to IGNORE the physical EOT reflective mark.  The software
that wrote it did the right thing, and you'll detect the EOF mark and EOT
records before you run out of tape.  (After all, you wrote them.)

If I had my copy of the ANSI standards, I could give you the exact physical
requirements and the exact label record and EOF mark layouts.  The point I'm
making is that THERE ARE STANDARDS.  The Unix world can and should follow them.
-- 

Anton	(...!{harvard,linus}!axiom!lpi!abc)

"Entropy isn't what it used to be."