Path: utzoo!censor!comspec!humvax!robohack!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.unix.i386
Subject: Re: Archive Tapes
Message-ID: <1990May4.224058.4271@eci386.uucp>
Date: 4 May 90 22:40:58 GMT
References: <29490@cup.portal.com> <1990May2.113532.26951@msuinfo.cl.msu.edu> <7804@dmshq.mn.org> <299@zds-ux.UUCP>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: Elegant Communications Inc., Toronto, Canada
Lines: 29

In article <299@zds-ux.UUCP> bjstaff@zds-ux.UUCP (Brad Staff) writes:
| 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.
 
| 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.)

I've yet to see a version of cpio that doesn't "handle" end of media...  
(Eg: System III source tapes...).  And have seen few versions of tar that *do*.

The problem is that cpio considers *any* read or write error to 
be end of tape and prompts for the next tape.  Which, if the tape is 
partially defective, is definately wrong.  I suspect that some of the 
other tape archivers do the same - I distinctly remember pax once continually 
reprompting me because I had write protect on the tape.  Bit confusing to 
say the least.

I wish that there was an end of media errno.  (Though some tape drivers
apparently do something slightly different on EOM versus true errors)
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list