Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!sdcsvax!ncr-sd!greg
From: greg@ncr-sd.UUCP (Greg Noel)
Newsgroups: net.unix-wizards
Subject: Re: need help with multi-reel cpio
Message-ID: <888@ncr-sd.UUCP>
Date: Tue, 20-May-86 00:54:21 EDT
Article-I.D.: ncr-sd.888
Posted: Tue May 20 00:54:21 1986
Date-Received: Fri, 23-May-86 06:16:36 EDT
References: <520@sdcc13.UUCP> <461@ncr-sd.UUCP> <529@isis.UUCP> <862@uqcspe.OZ>
Reply-To: greg@ncr-sd.UUCP (Greg Noel)
Organization: NCR Corporation, San Diego
Lines: 39
Keywords: cpio tape backup

In article <862@uqcspe.OZ> tony@uqcspe.UUCP writes:
>	What we did was write a filter to handle output from any program
>(e.g. cpio/tar/cat etc.) to write on several volumes. (e.g. floppies/tapes)
>It has been tested under V7 & Sys 3 and for several tapes and floppies.

This is, of course, the correct Unix way to do this sort of thing -- factor
out the common element into a seperate program that does that one thing well.
It's always been my thought that this should be done by the next-generation
version of "dd" since it is already somewhat specialized for handling tapes.
In fact, I once modified a V6 version of "dd" to do some of this, specificly
because I had some multi-volume tapes that I needed to process.  Everything
except the tape handling could be done by standard Unix utilities, and since
I already needed "dd" for the "conv=swab" option, I just tinkered with it
a bit to handle multiple volumes.  What I did was really a special-purpose
hack, but the fact that the idea has been independantly re-implemented (and
more than once -- I know of another case) shows that the generic idea is a
good one.

>	The doc follows :-
>
> .....  [ A description of a program that handles multiple-volume files.
>        Volume overflow on output is detected by pre-specifying how many
>        blocks can be made to fit on the volume.  Specificly: ]
>
>     .............   If  the  device  or  its
>     driver  does not allow successful writing all the way to the
>     end of a physical volume, such as with magnetic tape, the -n
>     count  options  should be used to specify the maximum number
>     of physical blocks to be written on one volume.

Aye, here's the rub -- all of the volumes must be at least this size.  In a
normal computer center, tapes are routinely shortened when a bad spot occurs
near the beginning.  Since these are the tapes you are likely to get when an
operator is doing your backups, you can't expect that some number of blocks
will fit on a tape volume unless you routinely waste several hundred feet on
every volume.  It is just the sort of restriction described in the paragraph
above that I wish to see eradicated.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA