Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!uunet!zds-ux!bjstaff
From: bjstaff@zds-ux.UUCP (Brad Staff)
Newsgroups: comp.unix.i386
Subject: Re: Archive Tapes
Message-ID: <299@zds-ux.UUCP>
Date: 3 May 90 18:55:07 GMT
References: <29490@cup.portal.com> <1990May2.113532.26951@msuinfo.cl.msu.edu> <7804@dmshq.mn.org>
Organization: Zenith Data Systems
Lines: 31

In article <7804@dmshq.mn.org>, pnessutt@dmshq.mn.org (Bob Monio) writes:
[ Some stuff deleted ]
> Some vendors have modified their tar and cpio programs to support 
> multiple volume archives.  NCR has done this with their cpio
> implementation.  But, not all vendors do this.  This is unfortunate
> since some people don't have the luxury of large capacity tape
> devices.
[ Some more stuff deleted ]

Interactive has done this with 386/ix.  Here is what I get when I run the
following command:  (Note that I am using the raw, not the block, floppy
device.)

$ find . -print | sort | cpio -ovB > /dev/rdsk/f0q15dt
Reached end of medium on output.
If you want to go on, type device/file name when ready.

All that is needed is to swap floppies and type '/dev/rdsk/f0q15dt' again.
The cpio that comes on the AT&T System V/386 Release 3.2 tape looks for ENOSPC
or ENXIO coming back in errno after read() and write() calls.  If it sees those
values it assumes it has reached the end of that piece of media and asks for a
new one.  If your cpio doesn't do this, complain to your vendor.  Of course,
your floppy and/or tape drivers have to be well behaved as well if this is
going to work.  If they aren't well behaved, complain to your vendor.

I hardly ever use tar, so I can't offer any suggestions there.
-- 
Brad Staff               |
Zenith Data Systems      | "A government that can forbid certain
616-982-5791             |  psychoactive drugs can mandate others."
bjstaff@zds-ux.zds.com   |	- Russell Turpin