need help with multi-reel cpio

[Jay Batson]

In article <461 at ncr-sd.UUCP> greg at ncr-sd.UUCP (Greg Noel) writes:
>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 
>  ..... [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...
>...
>No, the problem is with Unix's treatment of tape volumes.  Note that as it
>stands, Unix cannot even read a multi-volume tape produced on, say, an IBM
>system -- several blocks at the end of each reel are simply inaccessible.

I wondered why I seemed to get incomplete data from another outfit supplying
IBM produced tapes.

>And files produced by cpio, where the last block on the tape has no EOF after
>it, are difficult to read on an IBM machine, which expects one.
>
>So, what are we to do?  The cure is surprising -- and surprisingly simple:
>make Unix comply with the standard.  I don't know why it hasn't been done --
>although it would break any existing multi-reel cpio volumes (as far as I know,
>that's about the only program that ever creates multi-volume tapes by looking
>for an EOT), it won't break any other existing code (or it shouldn't), and new
>tapes would be guaranteed to be consistant across all possible machines.  It
>shouldn't be any problem to change, since multi-volume tapes don't seem very
>common -- notice the dearth of replies to this article since it was posted;
>there can't be many people who encounter this problem.

Maybe the dearth was because people, like me, didn't know the problem/fix.

>The mods are simple:...
>...
>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.......  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

I have been aggravated by lack of multi-reel/cartridge capability for quite
a while - I dummy up a fix by calculating the amount of tape I've used, and
simply close the tape file before I reach the EOT marker.  Although I get
pretty close, I waste maybe 50 - 100 feet of tape from time to time,
and it forces me to incorporate this dummy-fix write routine to make any
tape volumes that must be read reliably by other systems.  (PS - I'm doing
all this on a Systech multibus controller/Cipher 1/2" drive on an
``NCR Tower'' (Greg take note!!)

Standards groups are great, but it takes more than that - it will take
efforts by AT&T, UCB, and the system manufacturers who provide device drivers
for systems, and who \should/ be the central source for hacking up UNIX will
have to take the initiative.  Greg, has NCR done it in Rel 3....?  I'm
going to look at incorporating your fix in the driver I wrote for my
controller/tape.

Yes, standards groups, take note.  But more importantly, \AT&T/, \Berkley/,
and others - you are the ones who need to take note.  The fix seems so
basic.  Lets all take up Greg's "gauntlet" and "prove him wrong".
-----------------------------------------------------------------------------
Jay Batson    Energy Logic Systems, Inc., Denver, Colorado

seismo!hao!isis!jay             << preferred
          !isis!elsi!jay        << unreliable - like me