need help with multi-reel cpio

[Greg Noel]

I'll be gracious and assume that the reason that you are so far off the point
is that you either (a) didn't read the articles leading up to the one to which
you replied, or (b) didn't understand the article to which you replied.  I
normally wouldn't respond to something like that, but in this case, I think
it's important that people don't think that I actually meant the words you are
putting in my mouth.  I also want to correct some erroneous statements.

The context of the discussion was that Unix EOT semantics were neither (a)
internally consistant with themselves, nor (b) compatible with industry
standards.  The conversation had then drifted to how the Unix semantics
could be modified to correct these deficiencies.

In article <153 at lpi.UUCP> abc at lpi.UUCP (Anton Chernoff) writes:
>Sorry, but the standards require that you be able to write past the end of tape
>marker.

I didn't say that, and the fragement of my article you quoted strongly implied
that I felt it should be possible to write past the EOT marker (with suitable
restrictions).  But in point of fact, the standard doesn't \require/ that it
must be possible to write after the EOT marker; it just makes it \possible/ to
do a limited amount of writing after the EOT marker, if desired.  That's a very
different thing.

> ..... [Blather about how Itty Bitty Machines handles EOT, which includes
>		the remarkable statment ... ]
>you write right over the EOT marker!

This is not surprising.  The EOT marker is not even on the same side of the
tape as the magnetic recording surface.  Read/write and detecting the EOT are
completely independant operations.

>The EOT mark is ADVISORY ONLY.  It may NOT "prevent" the user from doing
>subsequent writes.

For Unix, this is just flat wrong.  If you do not "prevent" the user from
doing subsequent writes, how do you expect him to stop without running off
the end of the reel?  The issue under discussion was how to present the EOT
warning to the Unix process that did the write.  This has to be done in a
way that is compatible with current file semantics, i.e., programs that don't
know they are writing to a tape should be given an indication that they
understand -- like "write error".

>The right thing for Unix to do (under control of cpio or
>tar) is the SAME THING: finish the write, write an EOT record ....
>...... close/rewind the reel, and mount a new reel.

This is \exactly/ what I said in the article to which you are replying.  In
fact, this is \exactly/ what I said in the portion that you quoted.

> ....  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.)

Again, this is \exactly/ what I said, although in a prior article.

>.......  The point I'm
>making is that THERE ARE STANDARDS.  The Unix world can and should follow them.

Again, that is \exactly/ my argument.  Please don't put words in my mouth that I
don't mean.

Now, can we get back to the discussion, already in progress, of what semantics
should be specified for Unix (and clones) so that industry-standard tapes can
be read and written?
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg at ncr-sd.UUCP or Greg at nosc.ARPA