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