                   Hamilton Laboratories
                      13 Old Farm Road
              Wayland, MA  01778-3117, U.S.A.
                        508-358-5715
                     FAX:  508-358-1113

October 28, 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.  The
fundamental problem is the device driver shipped with
Windows NT:  it just isn't up to the same quality levels as
the rest of system.

   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.  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.  I genuinely wish there was a better
answer.  There is not.

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

Page 2

manually rewind the tape after each attempt, since otherwise
you'll end up just reading/writing from wherever the head
happened 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:

   If no contents are shown (and you know there's something
there on the tape) and there are no other error messages, it
means tar was told that it had reached a normal end-of-file.
Since an empty tar file is perfectly legal, tar can't tell
that anything went wrong.  Try manually specifying a
blocksize using the -B option, overriding the device
driver's suggestion to tar.  Usually 1024 is a good
blocksize.  You can try other blocksizes, 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.

Remember:  there's a guarantee!

   If you follow the suggestions outlined here, chances are
very good you'll get your tape drive to work.  But once
again, no one can make you a promise.  You will just have to
try it.

   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.


Page 6

   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
