need help with multi-reel cpio(

stone at vlad.UUCP stone at vlad.UUCP
Thu May 1 14:19:00 AEST 1986


/* Written 11:02 pm  Apr 28, 1986 by coleman at sdcsvax.UUCP in vlad:net.unix */
/* ---------- "Re: need help with multi-reel cpio(" ---------- */
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 
...
>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.
...
>No, the problem is with Unix's treatment of tape volumes.  Note that as it
...
>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. 

There are tape drives that cannot backspace(the qic-02 1/4" tape
standard doesn't even contain any spacing commands), so this is not a
general solution.  It seems like there are two other possible
solutions.  The archive systems(i.e., tar and cpio) could be modified to
understand that an archive may have fragmented blocks.  Or, the tape
drivers could be modified to understand the real nature of the EOT
assertion, and continue writing out the current block, but return on
error on the next block.  This would of course require that enough good 
tape exist after the EOT mark to contain the block; I'm not familer enough 
with the range of tape systems to know if this is an acceptable solution.

don
coleman at ucsd.edu
/* End of text from vlad:net.unix */



More information about the Comp.unix mailing list