Xref: utzoo comp.sys.att:10603 comp.unix.questions:26281 comp.unix.sysv386:1299
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: comp.sys.att,comp.unix.questions,comp.unix.sysv386
Subject: Re: cpio -ivt
Message-ID: <34947@cup.portal.com>
Date: 17 Oct 90 14:24:07 GMT
References: <1990Oct16.203913.18533@mccc.uucp>
Organization: The Portal System (TM)
Lines: 32

pjh@mccc.uucp (Pete Holsberg) in <1990Oct16.203913.18533@mccc.uucp> writes:

	AT&T SV/386 R3.2.2.  Shouldn't "cpio -itv < /dev/<tape_device>" give me
	a display of all the files on the tape???

Depends how the tape was written. On my systems (UNIXPC/3B1, CTIX, etc.) the
following commands work (rmt0 is normal tape, rmt2 causes an auto rewind;
both these are for a QIC-02 streamer; the other drive is referenced using
rft0 or rft3):

to write a tape:

	find * -print | cpio -ocT64 > /dev/rmt2

to restore (all) the tape:

	cpio -icdumT64 < /dev/rmt2

to get a directory of the tape's contents:

	cpio -ictvT64 < /dev/rmt2

If you wrote the tape with the 'c' option, you MUST use the 'c' option to
read it back.

The 'T64' selects a large buffer to prevent the ol' "shoeshining your data"
with streaming QIC tape drives; on my systems T128 also works ... the 'B'
option of cpio is simply too slow.  One could also write a double-buffering
routine to be piped, but that's a sophistication AFTER one is assured a tape
can be read.

Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]