[comp.sys.att] cpio -ivt

pjh@mccc.uucp (Pete Holsberg) (10/17/90)

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???

Pete
-- 
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu	     Trenton Computer Festival -- 4/20-21/91

mvadh@cbnews.att.com (andrew.d.hay) (10/17/90)

In article <1990Oct16.203913.18533@mccc.uucp>, pjh@mccc.uucp (Pete Holsberg) 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???

unless the archive was made with the -c option...

-- 
Andrew Hay		+------------------------------------------------------+
Ragged Individualist	| 	You just have _N_O idea!  It's the difference    |
AT&T-BL Ward Hill MA	|	between _S_H_O_O_T_I_N_G a bullet and _T_H_R_O_W_I_N_G it!     |
a.d.hay@att.com		+------------------------------------------------------+

thad@cup.portal.com (Thad P Floryan) (10/17/90)

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 ]

tneff@bfmny0.BFM.COM (Tom Neff) (10/19/90)

In article <34947@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>                                                              ... 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.

It doesn't take too much sophistication to put a 'dd bs=32k |' in front
of your cpio/tar/pax command.  This gives you double buffering without
having to write any code.

-- 
What luck for rulers that men   []+   Tom Neff
do not think. -- A. Hitler      +[]   tneff@bfmny0.BFM.COM

richard@pegasus.com (Richard Foulk) (10/22/90)

>>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.
>
>It doesn't take too much sophistication to put a 'dd bs=32k |' in front
>of your cpio/tar/pax command.  This gives you double buffering without
>having to write any code.

Or use "ddd" which is much better.  It's available from the comp.sources.unix
archives in volume 15.


-- 
Richard Foulk		richard@pegasus.com