Copying SunOS distribution tapes

[David L. Markowitz]

mkatz at sesame.stanford.edu (Morris Katz) writes:
>In article <2099 at brazos.Rice.edu>, MIKE at UCDHEP writes:
>>Hence, I'd like to do what seems to me to be the obvious thing, namely,
>>just copy the 1/4" tape to a 1/2" tape compatible with my drive.  I've
>>asked people around here who are more knowledgeable than I about SunOS if
>>that were possible.  The general sense of the replies is ``it's possible
>>in principle but not easy to do'', for reasons which are vague, at least
>>to me.

The main reason it is difficult is because of the limitations of the 1/4"
drives.  Any other direction is easy: 1/2" -> 1/2", 1/2" -> 1/4", and 1/4"
-> 1/4".  The limitation involved is based on the fact that the
information on a 1/2" tape consists of more than just the byte stream you
cann read from it.  Also of great importance is the record size.

[ Note: The following information is deducible by reading between the
lines of mtio(4) at least twice. ]

When read a 1/2" tape, you must read a large enough record to get all the
data: anything left will be discarded.  If you request too much you will
get only as much as is in the current record.  Subsequent reads will get
subsequent data records.

On the other hand, a 1/4" drive stores ONLY 512-byte records, and fakes
bigger records (multiples of 512) by returning as many records as are
needed to satisfy the request.  Reads of non-512 byte multiples are an
error.

What this means is that on a 1/2" tape you can tell that the tape has
three records of size 512, 2048, and 1024 bytes in that order (by reading
64K bytes three times and checking the return value from read()), but on a
1/4" tape there is no way to tell!

Because of that, you can't copy a 1/2" tape to a 1/4" tape without knowing
the structure ahead of time.  This info can't be deduced from the tape.
Sun's distribution tapes consist of many files with many, variable record
sizes (but always a multiple of 512).  In particular, the first file on
tape 1 (the "boot" program) starts with a 512 byte record and is followed
by many 2048 byte records.  Why?  I don't know.  Third base.

It then becomes obvious that a properly written copy program can copy 1/2"
-> 1/2" (record size deducible), 1/2" -> 1/4" (record size deducible and
unnecessary)), and 1/4" -> 1/4" (record size irrelevant).  I have written
such a beast.  It can copy over a network, too.

>The problem is that the distribution tapes come with a directory at the
>begining that lists their contents.  This directory is used by the
>installation software.  Since the different size tapes are of different
>length, one cannot just blindly copy the bits from one tape to another and
>have things work since splitting one tape over several tapes will cause
>the directory to be incorrect and cause problems.

This is also true, but I have never had problems copying a 60 MB tape to a
145 MB tape.  Just waste the excess, or use a 1200' tape.  If a 1600 bpi
tape is needed, that should fit too (Sun uses 450' 1/4" tapes so they
never have >45 MB).

>I have never tried it,
>but the last time I looked, the directory was just in ascii, so I imagine
>that one can build the correct directory by hand and store it at the
>begining of each tape.

Under 4.0 the directory is stored in XDR format.  Still massagable, but a
much tougher job.

>P.S.  I suspect that it is easiest just to get a loaned copy of the tapes
>from sun and copy them.  Sun has a disk to tape/tape to disk copy program
>that makes this easy.  Try and cajole you local sales rep into giving you
>a copy.

This program is a consulting special (tcopy can't handle this either).
Mine copies tape to tape (no disk space required, but you need two tape
drives on one network).  Borrow the 1/2" tapes and copy them.