From: thad@public.BTR.COM (Thaddeus P. Floryan)
Newsgroups: comp.unix.amiga
Subject: Re: Help me duplicate a QIC tape...
Date: 12 Apr 92 08:11:46 GMT
Organization: BTR Public Access UNIX, Mountain View CA

In article <3615@isc-br.ISC-BR.COM> ricks@odin.UUCP (Rick Schaeffer 99) writes:
>In article <4ppjj!c.harp@netcom.com> harp@netcom.com (Gregory O. Harp) writes:
>>
>>I need suggestions on how to duplicate a 150MB QIC tape using an Amiga
>>3000 (running AmigaDOS 2.04) and an A3070 tape drive.  Is there any
>>way to do this currently with only one tape drive?
>
>[...]
>      :
>      for name in `cat seglist`
>      do
>      	echo "Working on segment $name"
>      	dd if=/dev/rmt/4n of=$name bs=32k
>      done
>[...]

You made the assumption he wanted to dupe the Amiga UNIX install tape! :-)

There are two methods to precisely, exactly, and reliably duplicate a
non-regular, non-cpio/-tar tape (such as boot and/or install tapes):

(1)	copytape
	posted to comp.sources.misc circa 1986.
	it assumes you have sufficient disk space to hold the entire tape's
	contents

(2)	my tprobe program
	posted to alt.sources and comp.sources.unix mid-February 1992.
	it will dupe over Ethernet between two systems, or on a single system
	possessing two tape drives

As I'm getting weary of re-iterating this (due to all the related postings in
the alt.sys.sun, comp.sys.sun.* and comp.unix.misc group recently), I'll say
again:

dd(1) is great for duping cpio- or tar-written tapes whose >>> LOGICAL <<<
blocking across the tape is constant

dd(1) is NOT good for duping boot and/or install tapes whose LOGICAL blocking
changes for each save-set on the tape.  As many have discovered, using dd(1)
to dupe a 59.5MB content QIC-24 Sun boot tape required TWO DC600A tapes; my
tprobe (and the copytape) program makes EXACT copies onto a single tape.

The same variable LOGICAL blocking has been observed by me also on AT&T,
CTIX, UNISYS, and most other mfr's boot/install tapes.

I haven't used tprobe to analyze an Amiga UNIX tape yet, but it would be
interesting to see what it finds.

My original use of tprobe was to read a SunOS 4.1.1 boot tape on a 3B1
while duplicating it on a CTIX MightyFrame over Ethernet; I then full-installed
SunOS on one of m Suns from that copied tape (and the system is still running).

I've seen logical block size range from 3 blocks on up to n.  To use dd(1)
with its fixed bs is asking for potential trouble unless you can second-guess
how the system will respond to blocks larger than it is expecting.

tprobe, without ANY changes, has already been tested on ALL of:

	3B1 with AT&T 3.51m
	3B2 with AT&T SVR3.2.2
	SunOS 4.1.1 on Sun-3 and Sun-4 platforms
	UNISYS/CT CTIX 6.2.5 (SVR3.2.2) on MightyFrames
	Motorola 6300 and 6350 platforms with kernel FE07.*
	SGI IRIS
	HP-UX 7.* and 8.* (on HP 9000/8xx and 9000/3xx platforms)
	'386 and '486 boxes running SCO UNIX

So it should also work on Amiga UNIX.  I've emailed over 100 copies to people
who don't receive alt.sources (and I've over 200 more requests pending), and
not one problem has been reported back.

Though tprobe's sole raison d'etre is duplicating boot/install tapes, I also
use it for media conversions (QIC-11, QIC-24, QIC-120, QIC-150, QIC-525,
Exabyte, etc) and for duping critical backup tapes (because it's so easy to
use) per:

	tprobe -r /dev/nrst8 | tprobe -w /dev/nrst9

As explained in tprobe's manual, I wrote it to determine WHY dd(1) was so
unsuccessful duplicating various systems' boot/install tapes, and later added
the tape duping capability.  tprobe is actually a simple program, and I'm not
making any "Claimes of Magicke" for it!  :-)

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]