Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!calma!vlad!stone
From: stone@vlad.UUCP
Newsgroups: net.unix
Subject: Re: need help with multi-reel cpio(
Message-ID: <16000001@vlad>
Date: Thu, 1-May-86 00:19:00 EDT
Article-I.D.: vlad.16000001
Posted: Thu May  1 00:19:00 1986
Date-Received: Sat, 3-May-86 17:50:30 EDT
References: <1728@sdcsvax.UUCP>
Lines: 31
Nf-ID: #R:sdcsvax.UUCP:-172800:vlad:16000001:000:1629
Nf-From: vlad.UUCP!stone    Apr 30 21:19:00 1986


/* Written 11:02 pm  Apr 28, 1986 by coleman@sdcsvax.UUCP in vlad:net.unix */
/* ---------- "Re: need help with multi-reel cpio(" ---------- */
In article <461@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes:
>In article <520@sdcc13.UUCP> bparent@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@ucsd.edu
/* End of text from vlad:net.unix */