                   Hamilton Laboratories
                    21 Shadow Oak Drive
              Sudbury, MA  01776-3165, U.S.A.
                        508-440-8307
                     FAX:  508-440-8308

December 8, 1994

Subject:  Using tape drives with TAR

   The tar utility included with Hamilton C shell will
indeed work with most tape drives under Windows NT.  You may
find, however, that getting it to work will require a
certain unavoidable amount of experimentation.

   We find that QIC drives using DC-6525, DC-300, DC-600 and
similar full-size, quarter-inch, streaming cartridges are
generally the most reliable.  4mm DAT drives are also
generally very reliable, especially under NT 3.5.  Exabyte
8mm drives are occasionally more difficult; if you have an
older Exabyte that just refuses to work, you may need a
firmware update from Exabyte.  ``Floppy tapes'' -- those
using DC2120 minicartridges -- are apparently impossible; no
one we've talked to has ever made one of them work.

   The only way to know whether your tape drive can be used
with NT is to try it.

Getting help information from TAR and MT:

   These pages will outline just a few of the options that
tar and its accompanying mt (magnetic tape) utility provide.
If you need additional help from these (or any other)
Hamilton utilities, you can always get it using the -h
option.  Since the help information often runs to several
screenfuls, it's generally useful to pipe it to more, e.g.,
using the mi (more interactive) alias for more:

          tar -h | mi

Rewinding a tape:

   Tar normally rewinds the tape before and after reading or
writing it.  You can suppress that with the -N (no rewind)
option.

   In some of your experiments, you may want to try using
blksize to pipe data on/off the tape device.  Blksize is
deliberately trivial and does not automatically rewind the
tape.

   In experiments using blksize, you'll have to manually
rewind the tape after each attempt, since otherwise you'll
end up just reading/writing from wherever the head happened

Page 2

to be positioned on the tape.  You can manually rewind the
tape using the mt utility:

          mt rewind

Listing the contents of a TAR tape:

   To list the contents of a tape using the -L (Long
Listing) option so you can see in detail what's there:

          tar -L \\.\tape0

   The tape device is \\.\tape0 under NT.  If you have more
than one tape, the others will be called \\.\tape1,
\\.\tape2, etc.

   By default, tar will use whatever blocksize the device
driver recommends.  As it reads the tape, tar will
automatically recognize either tar or cpio formats
(including  both ASCII and binary versions of cpio) and will
automatically do whatever "byte-flipping" is required if the
tape was written on machine with a different byte-sex.  (All
NT machines are little-endian, meaning they write data
starting with the byte containing the least significant bits
first; many UNIX machines are big-endian, meaning they write
data in the opposite order.)

   For a little more diagnostic information from tar, you
can use the -v (verbose) option instead of -L.  You'll get
some additional information about what format (tar versus
cpio), bytesex and blocksize tar is using and the offsets
from the beginning of the archive at which each file in the
archive appears.

What to do if you can't read a tape:

   Unlike the device drivers in most UNIX systems which are
fairly forgiving and will let you read a tape using any
blocksize larger than what was used when the tape was
written, NT's drivers insist you must use the exact same
blocksize.  If you try using a different blocksize -- even
if it's larger -- it just won't work.  If you try, you
should get an error message from tar.  Try manually
specifying different blocksizes using the -B option,
overriding the device driver's suggestion to tar, until you
find one that works.  You can try anything, but keep in mind
that Microsoft makes no promise that any blocksize which is
not a power-of-2 times 512 will work.  Thus, e.g., the
common UNIX blocking factor of 20 (meaning 20 * 512 = 10,240
bytes) is not guaranteed to work.

   Here's how you might try to read the tape with a
blocksize of 1024:


                                                      Page 3

          tar -LB 1024 \\.\tape0

   You may get a warning message saying tar could not set
the blocksize on the device.  That means the device driver
is acting up and not accepting the normal setup commands
that tar was trying to issue but tar continued to try
reading data anyway.  You can try setting the blocksize and
then reading the tape drive as separate steps.   Here's an
example, using mt to set the blocksize and then using the
blksize utility in the samples directory to read the tape,
piping the output to tar.  The -s (stdio) option to tar
tells it that it should read the archive from stdin when
listing or extracting or write it to stdout if it's adding
files to the archive.

          mt blksize 1024
          blksize 1024 < \\.\tape0 | tar -Ls

   Blksize is a trivial "cat" utility (you'll find the
source in that same samples directory).  Blksize guarantees
to do all reads and writes (except the last) using the
specified blocksize.  Unlike tar, it pays no attention to
what it's reading from or writing to and skips over the
setup operations that tar was trying.  Once again, the trick
is to try various blocksizes until you find one that works.

   In some very rare cases, customers have observed they can
read the data from the tape using the blksize utility, but
only if they do not pipe the output to tar.  Apparently,
there is some kind of timing-dependent bug in the driver
that's triggered when some of the processor cycles are bled
off to the process running tar.  In this case, you may still
be able to read the tape, but only by ``staging'' it onto
your hard disk before running tar:

          blksize 1024 < \\.\tape0 > mytape.tar
          tar -L mytape.tar

   If you find that even by experimenting with these
techniques, you cannot read anything from the tape, it may
be that the blocksize used to record that tape is just not
supported on your hardware using the NT driver.  At that
point, it's time to try writing a new tape and seeing if
that can be read back.

Extracting the contents of a TAR tape:

   If you can list the contents of a tar tape, you can
extract it.  Do this using the same procedure you used to
list the contents of the tape, but adding the -x (Extract)
option.  For example, if yours was the simple case where tar
was able to read your tape directly with no need to specify
a blocksize or to pipe through the blksize utility:


Page 4

          tar -Lx \\.\tape0

   By default, tar will extract everything on the tape into
the current directory.  Refer to tar's help information for
other options.

Writing a TAR tape:

   To write a tape, adding one or more files or directories
to the archive:

          tar -La \\.\tape0 file1 file2 file3 ... filen

   You can list as many files or directories on the line as
you like.  All the usual wildcards can be used.  If one of
the items is a directory, the entire contents of that
directory will be copied to the tape.

Check that you can read the tape you just wrote!

   After writing a tape, do be sure to check that you can
read it back.  This is just a safety precaution the first
time you try using your drive or a new setting for
blocksize, etc.

   If you discover you can't read anything back, it's
probably because you tried (or defaulted to) a blocksize
that doesn't work.  Your strategy for experimentation should
be similar to that outlined in the section on listing the
contents of a tape.  Try explicitly specifying a blocksize
(e.g., 1024) to tar using the -B option.  Here's an example,
archiving the entire current directory to the tape:

          tar -LaB 1024 \\.\tape0 .

   If that doesn't work, try piping the output of tar to
blksize, redirected to the tape drive:

          tar -Las . | blksize 1024 > \\.\tape0

   If that doesn't work, try creating the tar archive on
disk, then copying it to the tape drive in a separate step,
e.g.:

          tar -La \tmp\archive.tar .
          blksize 1024 < \tmp\archive.tar > \\.\tape0

   The trick is to keep experimenting and to be sure that if
it looks like you wrote a tape successfully, that you can
read it back.  The good news is that once you find a
procedure that works on your system, it will (in our
experience) be reliable.

Exchanging tapes with a UNIX system:


                                                      Page 5

   If you find that you can read tapes that you've written
but not tapes written on another machine, then the problem
is likely that the blocksize that was used on the other
machine is one you can't read.  Fortunately, most UNIX
systems have very robust device drivers, capable of
reading/writing almost any reasonable blocksize.

   In that case, your strategy should be to tell the
operator on the UNIX machine what blocksizes you found
worked for you.  (Remember, you can use the tar -v option to
help you.)  If there's any question, take a tape written
under NT to the UNIX machine and use the tools there to
diagnose the actual blocksize.

   If the UNIX machine can read the data from your tape, but
it comes out garbled, the problem is probably that you've
written the data in the wrong bytesex.  (UNIX tar utilities
don't know how to do automatic byteswapping.)  This is easy
to fix.  Use the tar -b (bytesex) option to specify a
different ordering when you write the tape next time.
Here's an example, writing all the .c and .h files in the
current directory to a tape in big-endian format:

          tar -Lab badc \\.\tape0 *.[ch]

ASCII text versus binary files:

   One final consideration is that UNIX and NT differ on
their line-end conventions.  UNIX uses a single newline (\n)
character to mark the end of a line; NT uses a carriage
return-newline (\r\n) combination.  Hamilton tar assumes
that because tar is fundamentally a UNIX format, that any
ASCII files stored in a tar file will probably follow the
UNIX convention.  Consequently, when extracting an ASCII
text file, tar will convert from \n to \r\n; when adding a
file to the archive, it will do the reverse.  Binary files
are not converted.

   You can override this default behavior by specifying
either -r to turn off any conversions.  The -R option causes
conversions to always be done, even on files that appear to
be binary.  You can also use the TARBINARY and TARASCII
environment variables to list files that should be
considered as being one type versus the other based on the
filename, regardless of content. For example, database
products often create files with a lot of ASCII data but
which really should considered as binary.  Postscript files
with encapsulated images are another example.  These files
should never be translated as if they were ordinary ASCII
files.  You can indicate that by setting the TARBINARY
environment variable.  For example, in the System applet in
the Control Panel, you might set TARBINARY = *.ps to make it
treat all Postscript files as binary data.


Page 6

Remember:  there's a guarantee!

   If you follow the suggestions outlined here, chances are
very good you'll get your tape drive to work.  Certainly, if
you have any questions or if you get stuck and need help
going through these procedures, give me a call.  That's what
you've paid for.

   Finally, rest assured that the unconditional satisfaction
guarantee offered with Hamilton C shell means what it sounds
like:  if you decide you're not completely satisfied for any
reason -- or even for no reason! -- you get your money back.
I guarantee it!

Best regards,

Douglas A. Hamilton
