This is Info file tar.info, produced by Makeinfo version 1.67 from the
input file tar.texi.

START-INFO-DIR-ENTRY
* tar: (tar).			Making tape (or disk) archives.
END-INFO-DIR-ENTRY

   This file documents GNU `tar', a utility used to store, backup, and
transport files.

   Copyright (C) 1992, 1994, 1995, 1996, 1997 Free Software Foundation,
Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Foundation.

   This file documents GNU `tar', which is a utility used to store,
backup, and transport files.  `tar' is a tape (or disk) archiver.  This
manual documents the release 1.12a.


File: tar.info,  Node: cpio,  Prev: Extensions,  Up: Formats

Comparison of `tar' and `cpio'
==============================

     *(This message will disappear, once this node revised.)*

   The `cpio' archive formats, like `tar', do have maximum pathname
lengths.  The binary and old ASCII formats have a max path length of
256, and the new ASCII and CRC ASCII formats have a max path length of
1024.  GNU `cpio' can read and write archives with arbitrary pathname
lengths, but other `cpio' implementations may crash unexplainedly
trying to read them.

   `tar' handles symbolic links in the form in which it comes in BSD;
`cpio' doesn't handle symbolic links in the form in which it comes in
System V prior to SVR4, and some vendors may have added symlinks to
their system without enhancing `cpio' to know about them.  Others may
have enhanced it in a way other than the way I did it at Sun, and which
was adopted by AT&T (and which is, I think, also present in the `cpio'
that Berkeley picked up from AT&T and put into a later BSD release--I
think I gave them my changes).

   (SVR4 does some funny stuff with `tar'; basically, its `cpio' can
handle `tar' format input, and write it on output, and it probably
handles symbolic links.  They may not have bothered doing anything to
enhance `tar' as a result.)

   `cpio' handles special files; traditional `tar' doesn't.

   `tar' comes with V7, System III, System V, and BSD source; `cpio'
comes only with System III, System V, and later BSD (4.3-tahoe and
later).

   `tar''s way of handling multiple hard links to a file can handle
file systems that support 32-bit inumbers (e.g., the BSD file system);
`cpio's way requires you to play some games (in its "binary" format,
i-numbers are only 16 bits, and in its "portable ASCII" format, they're
18 bits--it would have to play games with the "file system ID" field of
the header to make sure that the file system ID/i-number pairs of
different files were always different), and I don't know which `cpio's,
if any, play those games.  Those that don't might get confused and
think two files are the same file when they're not, and make hard links
between them.

   `tar's way of handling multiple hard links to a file places only one
copy of the link on the tape, but the name attached to that copy is the
*only* one you can use to retrieve the file; `cpio's way puts one copy
for every link, but you can retrieve it using any of the names.

     What type of check sum (if any) is used, and how is this
     calculated?

   See the attached manual pages for `tar' and `cpio' format.  `tar'
uses a checksum which is the sum of all the bytes in the `tar' header
for a file; `cpio' uses no checksum.

     Does anyone know why `cpio' was made when `tar' was present at the
     unix scene?

   It wasn't.  `cpio' first showed up in PWB/UNIX 1.0; no
generally-available version of UNIX had `tar' at the time.  I don't
know whether any version that was generally available *within AT&T* had
`tar', or, if so, whether the people within AT&T who did `cpio' knew
about it.

   On restore, if there is a corruption on a tape, `tar' will stop at
that point, while `cpio' will skip over it and try to restore the rest
of the files.

   The main difference is just in the command syntax and header format.

   `tar' is a little more tape-oriented in that everything is blocked
to start on a record boundary.

     Is there any differences between the ability to recover crashed
     archives between the two of them?  (Is there any chance of
     recovering crashed archives at all?)

   Theoretically, it should be easier under `tar' since the blocking
lets you find a header with some variation of `dd skip=NN'.  However,
modern `cpio''s and variations have an option to just search for the
next file header after an error with a reasonable chance of re-syncing.
Note that lots of tape driver software won't allow you to continue
past a media error which should be the only reason for getting out of
sync unless a file changed sizes while you were writing the archive.

     If anyone knows why `cpio' was made when `tar' was present at the
     unix scene, please tell me about this too.

   Probably because it is more media efficient (by not blocking
everything and using only the space needed for the headers where `tar'
always uses 512 bytes per file header) and it knows how to archive
special files.

   You might want to look at the freely available alternatives.  The
major ones are `afio', GNU `tar', and `pax', each of which have their
own extensions with some backwards compatibility.

   Sparse files were `tar'red as sparse files (which you can easily
test, because the resulting archive gets smaller, and GNU `cpio' can no
longer read it).


File: tar.info,  Node: Media,  Next: tar invocation,  Prev: Formats,  Up: Top

Tapes and Other Archive Media
*****************************

     *(This message will disappear, once this node revised.)*

   A few special cases about tape handling warrant more detailed
description.  These special cases are discussed below.

   Many complexities surround the use of `tar' on tape drives.  Since
the creation and manipulation of archives located on magnetic tape was
the original purpose of `tar', it contains many features making such
manipulation easier.

   Archives are usually written on dismountable media--tape cartridges,
mag tapes, or floppy disks.

   The amount of data a tape or disk holds depends not only on its size,
but also on how it is formatted.  A 2400 foot long reel of mag tape
holds 40 megabytes of data when formated at 1600 bits per inch.  The
physically smaller EXABYTE tape cartridge holds 2.3 gigabytes.

   Magnetic media are re-usable--once the archive on a tape is no longer
needed, the archive can be erased and the tape or disk used over.
Media quality does deteriorate with use, however.  Most tapes or disks
should be discarded when they begin to produce data errors.  EXABYTE
tape cartridges should be discarded when they generate an "error count"
(number of non-usable bits) of more than 10k.

   Magnetic media are written and erased using magnetic fields, and
should be protected from such fields to avoid damage to stored data.
Sticking a floppy disk to a filing cabinet using a magnet is probably
not a good idea.

* Menu:

* Device::                      Device selection and switching
* Remote Tape Server::
* Common Problems and Solutions::
* Blocking::                    Blocking
* Many::                        Many archives on one tape
* Using Multiple Tapes::        Using Multiple Tapes
* label::                       Including a Label in the Archive
* verify::
* Write Protection::


File: tar.info,  Node: Device,  Next: Remote Tape Server,  Prev: Media,  Up: Media

Device Selection and Switching
==============================

     *(This message will disappear, once this node revised.)*

`-f [HOSTNAME:]FILE'
`--file=[HOSTNAME:]FILE'
     Use archive file or device FILE on HOSTNAME.

   This option is used to specify the file name of the archive `tar'
works on.

   If the file name is `-', `tar' reads the archive from standard input
(when listing or extracting), or writes it to standard output (when
creating).  If the `-' file name is given when updating an archive,
`tar' will read the original archive from its standard input, and will
write the entire new archive to its standard output.

   If the file name contains a `:', it is interpreted as `hostname:file
name'.  If the HOSTNAME contains an "at" sign (`@'), it is treated as
`user@hostname:file name'.  In either case, `tar' will invoke the
command `rsh' (or `remsh') to start up an `/etc/rmt' on the remote
machine.  If you give an alternate login name, it will be given to the
`rsh'.  Naturally, the remote machine must have an executable
`/etc/rmt'.  This program is free software from the University of
California, and a copy of the source code can be found with the sources
for `tar'; it's compiled and installed by default.

   Since absolute file names on MS-DOS and MS-Windows include a drive
letter, like in `d:/dir/subdir/file', `tar' compiled for these
platforms does not treat file names with `:' as remote files if there
is a single letter before the colon.  `tar' also does not currently
support archives on remote machines when it runs on MS-DOS/MS-Windows.

   If `--file=ARCHIVE-NAME' (`-f ARCHIVE-NAME') is not given, but the
environment variable `TAPE' is set, its value is used; otherwise, old
versions of `tar' used a default archive name (which was picked when
`tar' was compiled).  The default is normally set up to be the "first"
tape drive or other transportable I/O medium on the system.

   Starting with version 1.11.5, GNU `tar' uses standard input and
standard output as the default device, and I will not try anymore
supporting automatic device detection at installation time.  This was
failing really in so many cases that it was hopeless to repair.  This
is now completely left to the installer to override standard input and
standard output for default device, if this seems preferrable to
him/her.  Further, I think *most* actual usages of `tar' are done with
pipes or disks, not really tapes, cartridges or diskettes.

   Some users think that using standard input and output is running
after trouble.  This could lead to a nasty surprise on your screen if
you forget to specify an output file name--especially if you are going
through a network or terminal server capable of buffering large amounts
of output.  We had so many bug reports in that area of configuring
default tapes automatically, and so many contradicting requests, that
we finally consider the problem to be portably intractable.  We could
of course use something like `/dev/tape' as a default, but this is
*also* running after various kind of trouble, going from hung processes
to accidental destruction of real tapes.  After having seen all this
mess, using standard input and output as a default really sounds like
the only clean choice left, and a very useful one too.

   GNU `tar' reads and writes archive in records, I suspect this is the
main reason why block devices are preferred over character devices.
Most probably, block devices are more efficient too.  The installer
could also check for `DEFTAPE' in `<sys/mtio.h>'.

`--force-local'
     Treat the archive file as local even if it contains a colon.  (The
     MS-DOS version always treats DOS-style absolute file names with a
     drive letter as local.)

`--rsh-command=COMMAND'
     Use remote COMMAND instead of `rsh'.  This option exists so that
     people who use something other than the standard `rsh' (e.g., a
     Kerberized `rsh') can access a remote device.

     When this option is not used, the shell command found when the
     `tar' program was installed is used instead.  This is the first
     found of `/usr/ucb/rsh', `/usr/bin/remsh', `/usr/bin/rsh',
     `/usr/bsd/rsh' or `/usr/bin/nsh'.  The installer may have
     overriden this by defining the environment variable `RSH' *at
     installation time*.

`-[0-7][lmh]'
     Specify drive and density.  (Not supported on MS-DOS/MS-Windows.)

`-M'
`--multi-volume'
     Create/list/extract multi-volume archive.

     This option causes `tar' to write a "multi-volume" archive--one
     that may be larger than will fit on the medium used to hold it.
     *Note Multi-Volume Archives::.

`-L NUM'
`--tape-length=NUM'
     Change tape after writing NUM x 1024 bytes.

     This option might be useful when your tape drivers do not properly
     detect end of physical tapes.  By being slightly conservative on
     the maximum tape length, you might avoid the problem entirely.

`-F FILE'
`--info-script=FILE'
`--new-volume-script=FILE'
     Execute `file' at end of each tape.  This implies `--multi-volume'
     (`-M').


File: tar.info,  Node: Remote Tape Server,  Next: Common Problems and Solutions,  Prev: Device,  Up: Media

The Remote Tape Server
======================

   In order to access the tape drive on a remote machine, `tar' uses
the remote tape server written at the University of California at
Berkeley.  The remote tape server must be installed as `/etc/rmt' on
any machine whose tape drive you want to use.  `tar' calls `/etc/rmt'
by running an `rsh' or `remsh' to the remote machine, optionally using
a different login name if one is supplied.

   A copy of the source for the remote tape server is provided.  It is
Copyright (C) 1983 by the Regents of the University of California, but
can be freely distributed.  Instructions for compiling and installing
it are included in the `Makefile'.

   Unless you use the `--absolute-names' (`-P') option, GNU `tar' will
not allow you to create an archive that contains absolute file names (a
file name beginning with `/'.) If you try, `tar' will automatically
remove the leading `/' from the file names it stores in the archive.
(On MS-DOS/MS-Windows, `tar' also removes the drive specification
`d:/'.)  It will also type a warning message telling you that it is
doing so.

   When reading an archive that was created with a different `tar'
program, GNU `tar' automatically extracts entries in the archive which
have absolute file names as if the file names were not absolute.

   For example, if the archive contained a file `/usr/bin/computoy',
GNU `tar' would extract the file to `usr/bin/computoy', relative to the
current directory.  If you want to extract the files in an archive to
the same absolute names that they had when the archive was created, you
should do a `cd /' before extracting the files from the archive, or you
should either use the `--absolute-names' (`-P') option, or use the
command `tar -C / ...'.  (On MS-DOS, include the drive specification in
the `-C' option, or change the current drive before the `cd' command.)

   This is an important feature.  A visitor here once gave a `tar' tape
to an operator to restore; the operator used Sun `tar' instead of GNU
`tar', and the result was that it replaced large portions of our `/bin'
and friends with versions from the tape; needless to say, we were
unhappy about having to recover the file system from backup tapes.

   Some versions of Unix (Ultrix 3.1 is known to have this problem),
can claim that a short write near the end of a tape succeeded, when it
actually failed.  This will result in the -M option not working
correctly.  The best workaround at the moment is to use a significantly
larger blocking factor than the default 20.

   In order to update an archive, `tar' must be able to backspace the
archive in order to reread or rewrite a record that was just read (or
written).  This is currently possible only on two kinds of files: normal
disk files (or any other file that can be backspaced with `lseek'), and
industry-standard 9-track magnetic tape (or any other kind of tape that
can be backspaced with the `MTIOCTOP' `ioctl'.

   This means that the `--append' (`-r'), `--update' (`-u'),
`--concatenate' (`--catenate', `-A'), and `--delete' commands will not
work on any other kind of file.  Some media simply cannot be
backspaced, which means these commands and options will never be able
to work on them.  These non-backspacing media include pipes and
cartridge tape drives.

   Some other media can be backspaced, and `tar' will work on them once
`tar' is modified to do so.

   Archives created with the `--multi-volume' (`-M'),
`--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL'), and `--incremental'
(`-G') options may not be readable by other version of `tar'.  In
particular, restoring a file that was split over a volume boundary will
require some careful work with `dd', if it can be done at all.  Other
versions of `tar' may also create an empty file whose name is that of
the volume header.  Some versions of `tar' may create normal files
instead of directories archived with the `--incremental' (`-G') option.


File: tar.info,  Node: Common Problems and Solutions,  Next: Blocking,  Prev: Remote Tape Server,  Up: Media

Some Common Problems and their Solutions
========================================

errors from system:
permission denied
no such file or directory
not owner

errors from `tar':
directory checksum error
header format error

errors from media/system:
i/o error
device busy


File: tar.info,  Node: Blocking,  Next: Many,  Prev: Common Problems and Solutions,  Up: Media

Blocking
========

     *(This message will disappear, once this node revised.)*

   "Block" and "record" terminology is rather confused, and it is also
confusing to the expert reader.  On the other hand, readers who are new
to the field have a fresh mind, and they may safely skip the next two
paragraphs, as the remainder of this manual uses those two terms in a
quite consistent way.

   John Gilmore, the writer of the public domain `tar' from which GNU
`tar' was originally derived, wrote (June 1995):

     The nomenclature of tape drives comes from IBM, where I believe
     they were invented for the IBM 650 or so.  On IBM mainframes, what
     is recorded on tape are tape blocks.  The logical organization of
     data is into records.  There are various ways of putting records
     into blocks, including `F' (fixed sized records), `V' (variable
     sized records), `FB' (fixed blocked: fixed size records, N to a
     block), `VB' (variable size records, N to a block), `VSB'
     (variable spanned blocked: variable sized records that can occupy
     more than one block), etc.  The `JCL' `DD RECFORM=' parameter
     specified this to the operating system.

     The Unix man page on `tar' was totally confused about this.  When
     I wrote `PD TAR', I used the historically correct terminology
     (`tar' writes data records, which are grouped into blocks).  It
     appears that the bogus terminology made it into POSIX (no surprise
     here), and now Franc,ois has migrated that terminology back into
     the source code too.

   The term "physical block" means the basic transfer chunk from or to
a device, after which reading or writing may stop without anything
being lost.  In this manual, the term "block" usually refers to a disk
physical block, *assuming* that each disk block is 512 bytes in length.
It is true that some disk devices have different physical blocks, but
`tar' ignores these differences in its own format, which is meant to be
portable, so a `tar' block is always 512 bytes in length, and "block"
always means a `tar' block.  The term "logical block" often represents
the basic chunk of allocation of many disk blocks as a single entity,
which the operating system treats somewhat atomically; this concept is
only barely used in GNU `tar'.

   The term "physical record" is another way of speaking about a
physical block, those two terms are somewhat interchangeable.  In this
manual, the term "record" usually refers to a tape physical block,
*assuming* that the `tar' archive is kept on magnetic tape.  It is true
that archives may be put on disk or used with pipes, but nevertheless,
`tar' tries to read and write the archive one "record" at a time,
whatever the medium in use.  One record is made up of an integral
number of blocks, and this operation of putting many disk blocks into a
single tape block is called "reblocking", or more simply, "blocking".
The term "logical record" refers to the logical organization of many
characters into something meaningful to the application.  The term
"unit record" describes a small set of characters which are transmitted
whole to or by the application, and often refers to a line of text.
Those two last terms are unrelated to what we call a "record" in GNU
`tar'.

   When writing to tapes, `tar' writes the contents of the archive in
chunks known as "records".  To change the default blocking factor, use
the `--blocking-factor=BLOCKS' (`-b BLOCKS') option.  Each record will
then be composed of 512-SIZE blocks.  (Each `tar' block is 512 bytes.
*Note Standard::.)  Each file written to the archive uses at least one
full record.  As a result, using a larger record size can result in
more wasted space for small files.  On the other hand, a larger record
size can often be read and written much more efficiently.

   Further complicating the problem is that some tape drives ignore the
blocking entirely.  For these, a larger record size can still improve
performance (because the software layers above the tape drive still
honor the blocking), but not as dramatically as on tape drives that
honor blocking.

   When reading an archive, `tar' can usually figure out the record
size on itself.  When this is the case, and a non-standard record size
was used when the archive was created, `tar' will print a message about
a non-standard blocking factor, and then operate normally.  On some
tape devices, however, `tar' cannot figure out the record size itself.
On most of those, you can specify a blocking factor (with
`--blocking-factor=BLOCKS' (`-b BLOCKS')) larger than the actual
blocking factor, and then use the `--read-full-records' (`-B') option.
(If you specify a blocking factor with `--blocking-factor=BLOCKS' (`-b
BLOCKS') and don't use the `--read-full-records' (`-B') option, then
`tar' will not attempt to figure out the recording size itself.)  On
some devices, you must always specify the record size exactly with
`--blocking-factor=BLOCKS' (`-b BLOCKS') when reading, because `tar'
cannot figure it out.  In any case, use `--list' (`-t') before doing any
extractions to see whether `tar' is reading the archive correctly.

   `tar' blocks are all fixed size (512 bytes), and its scheme for
putting them into records is to put a whole number of them (one or
more) into each record.  `tar' records are all the same size; at the
end of the file there's a block containing all zeros, which is how you
tell that the remainder of the last record(s) are garbage.

   In a standard `tar' file (no options), the block size is 512 and the
record size is 10240, for a blocking factor of 20.  What the
`--blocking-factor=BLOCKS' (`-b BLOCKS') option does is sets the
blocking factor, changing the record size while leaving the block size
at 512 bytes.  20 was fine for ancient 800 or 1600 bpi reel-to-reel
tape drives; most tape drives these days prefer much bigger records in
order to stream and not waste tape.  When writing tapes for myself,
some tend to use a factor of the order of 2048, say, giving a record
size of around one megabyte.

   If you use a blocking factor larger than 20, older `tar' programs
might not be able to read the archive, so we recommend this as a limit
to use in practice.  GNU `tar', however, will support arbitrarily large
record sizes, limited only by the amount of virtual memory or the
physical characteristics of the tape device.

* Menu:

* Format Variations::           Format Variations
* Blocking Factor::             The Blocking Factor of an Archive


File: tar.info,  Node: Format Variations,  Next: Blocking Factor,  Prev: Blocking,  Up: Blocking

Format Variations
-----------------

     *(This message will disappear, once this node revised.)*

   Format parameters specify how an archive is written on the archive
media.  The best choice of format parameters will vary depending on the
type and number of files being archived, and on the media used to store
the archive.

   To specify format parameters when accessing or creating an archive,
you can use the options described in the following sections.  If you do
not specify any format parameters, `tar' uses default parameters.  You
cannot modify a compressed archive.  If you create an archive with the
`--blocking-factor=BLOCKS' (`-b BLOCKS') option specified
(*note Blocking Factor::.), you must specify that blocking-factor when
operating on the archive.  *Note Formats::, for other examples of
format parameter considerations.


File: tar.info,  Node: Blocking Factor,  Prev: Format Variations,  Up: Blocking

The Blocking Factor of an Archive
---------------------------------

     *(This message will disappear, once this node revised.)*

   The data in an archive is grouped into blocks, which are 512 bytes.
Blocks are read and written in whole number multiples called "records".
The number of blocks in a record (ie. the size of a record in units of
512 bytes) is called the "blocking factor".  The
`--blocking-factor=BLOCKS' (`-b BLOCKS') option specifies the blocking
factor of an archive.  The default blocking factor is typically 20 (ie.
10240 bytes), but can be specified at installation.  To find out the
blocking factor of an existing archive, use `tar --list
--file=ARCHIVE-NAME'.  This may not work on some devices.

   Records are separated by gaps, which waste space on the archive
media.  If you are archiving on magnetic tape, using a larger blocking
factor (and therefore larger records) provides faster throughput and
allows you to fit more data on a tape (because there are fewer gaps).
If you are archiving on cartridge, a very large blocking factor (say
126 or more) greatly increases performance. A smaller blocking factor,
on the other hand, may be usefull when archiving small files, to avoid
archiving lots of nulls as `tar' fills out the archive to the end of
the record.  In general, the ideal record size depends on the size of
the inter-record gaps on the tape you are using, and the average size
of the files you are archiving.  *Note create::, for information on
writing archives.

   Archives with blocking factors larger than 20 cannot be read by very
old versions of `tar', or by some newer versions of `tar' running on
old machines with small address spaces.  With GNU `tar', the blocking
factor of an archive is limited only by the maximum record size of the
device containing the archive, or by the amount of available virtual
memory.

   Also, on some systems, not using adequate blocking factors, as
sometimes imposed by the device drivers, may yield unexpected
diagnostics.  For example, this has been reported:

     Cannot write to /dev/dlt: Invalid argument

In such cases, it sometimes happen that the `tar' bundled by the system
is aware of block size idiosyncrasies, while GNU `tar' requires an
explicit specification for the block size, which it cannot guess.  This
yields some people to consider GNU `tar' is misbehaving, because by
comparison, `the bundle `tar' works OK'.  Adding `-b 256', for example,
might resolve the problem.

   If you use a non-default blocking factor when you create an archive,
you must specify the same blocking factor when you modify that archive.
Some archive devices will also require you to specify the blocking
factor when reading that archive, however this is not typically the
case.  Usually, you can use `--list' (`-t') without specifying a
blocking factor--`tar' reports a non-default record size and then lists
the archive members as it would normally.  To extract files from an
archive with a non-standard blocking factor (particularly if you're not
sure what the blocking factor is), you can usually use the
`--read-full-records' (`-B') option while specifying a blocking factor
larger then the blocking factor of the archive (ie. `tar --extract
--read-full-records --blocking-factor=300').  *Note list::, for more
information on the `--list' (`-t') subcommand.  *Note Reading::, for a
more detailed explanation of that option.

`--blocking-factor=NUMBER'
`-b NUMBER'
     Specifies the blocking factor of an archive.  Can be used with any
     subcommand, but is usually not necessary with `--list' (`-t').

   Device blocking

`-b BLOCKS'
`--blocking-factor=BLOCKS'
     Set record size to BLOCKS * 512 bytes.

     This option is used to specify a "blocking factor" for the archive.
     When reading or writing the archive, `tar', will do reads and
     writes of the archive in records of BLOCK*512 bytes.  This is true
     even when the archive is compressed.  Some devices requires that
     all write subcommands be a multiple of a certain size, and so,
     `tar' pads the archive out to the next record boundary.

     The default blocking factor is set when `tar' is compiled, and is
     typically 20.  Blocking factors larger than 20 cannot be read by
     very old versions of `tar', or by some newer versions of `tar'
     running on old machines with small address spaces.

     With a magnetic tape, larger records give faster throughput and fit
     more data on a tape (because there are fewer inter-record gaps).
     If the archive is in a disk file or a pipe, you may want to specify
     a smaller blocking factor, since a large one will result in a large
     number of null bytes at the end of the archive.

     When writing cartridge or other streaming tapes, a much larger
     blocking factor (say 126 or more) will greatly increase
     performance.  However, you must specify the same blocking factor
     when reading or updating the archive.

     Apparently, Exabyte drives have a physical block size of 8K bytes.
     If we choose our blocksize as a multiple of 8k bytes, then the
     problem seems to dissapper.  Id est, we are using block size of
     112 right now, and we haven't had the problem since we switched...

     With GNU `tar' the blocking factor is limited only by the maximum
     record size of the device containing the archive, or by the amount
     of available virtual memory.

     However, deblocking or reblocking is virtually avoided in a special
     case which often occurs in practice, but which requires all the
     following conditions to be simultaneously true:
        * the archive is subject to a compression option,

        * the archive is not handled through standard input or output,
          nor redirected nor piped,

        * the archive is directly handled to a local disk, instead of
          any special device,

        * `--blocking-factor=BLOCKS' (`-b BLOCKS') is not explicitely
          specified on the `tar' invocation.

     In previous versions of GNU `tar', the `--compress-block' option
     (or even older: `--block-compress') was necessary to reblock
     compressed archives.  It is now a dummy option just asking not to
     be used, and otherwise ignored.  If the output goes directly to a
     local disk, and not through stdout, then the last write is not
     extended to a full record size.  Otherwise, reblocking occurs.
     Here are a few other remarks on this topic:

        * `gzip' will complain about trailing garbage if asked to
          uncompress a compressed archive on tape, there is an option
          to turn the message off, but it breaks the regularity of
          simply having to use `PROG -d' for decompression.  It would
          be nice if gzip was silently ignoring any number of trailing
          zeros.  I'll ask Jean-loup Gailly, by sending a copy of this
          message to him.

        * `compress' does not show this problem, but as Jean-loup
          pointed out to Michael, `compress -d' silently adds garbage
          after the result of decompression, which tar ignores because
          it already recognized its end-of-file indicator.  So this bug
          may be safely ignored.

        * `gzip -d -q' will be silent about the trailing zeros indeed,
          but will still return an exit status of 2 which tar reports
          in turn.  `tar' might ignore the exit status returned, but I
          hate doing that, as it weakens the protection `tar' offers
          users against other possible problems at decompression time.
          If `gzip' was silently skipping trailing zeros *and* also
          avoiding setting the exit status in this innocuous case, that
          would solve this situation.

        * `tar' should become more solid at not stopping to read a pipe
          at the first null block encountered.  This inelegantly breaks
          the pipe.  `tar' should rather drain the pipe out before
          exiting itself.

`-i'
`--ignore-zeros'
     Ignore blocks of zeros in archive (means EOF).

     The `--ignore-zeros' (`-i') option causes `tar' to ignore blocks
     of zeros in the archive.  Normally a block of zeros indicates the
     end of the archive, but when reading a damaged archive, or one
     which was created by `cat'-ing several archives together, this
     option allows `tar' to read the entire archive.  This option is
     not on by default because many versions of `tar' write garbage
     after the zeroed blocks.

     Note that this option causes `tar' to read to the end of the
     archive file, which may sometimes avoid problems when multiple
     files are stored on a single physical tape.

`-B'
`--read-full-records'
     Reblock as we read (for reading 4.2BSD pipes).

     If `--read-full-records' (`-B') is used, `tar' will not panic if an
     attempt to read a record from the archive does not return a full
     record.  Instead, `tar' will keep reading until it has obtained a
     full record.

     This option is turned on by default when `tar' is reading an
     archive from standard input, or from a remote machine.  This is
     because on BSD Unix systems, a read of a pipe will return however
     much happens to be in the pipe, even if it is less than `tar'
     requested.  If this option was not used, `tar' would fail as soon
     as it read an incomplete record from the pipe.

     This option is also useful with the commands for updating an
     archive.

   Tape blocking

   When handling various tapes or cartridges, you have to take care of
selecting a proper blocking, that is, the number of disk blocks you put
together as a single tape block on the tape, without intervening tape
gaps.  A "tape gap" is a small landing area on the tape with no
information on it, used for decelerating the tape to a full stop, and
for later regaining the reading or writing speed.  When the tape driver
starts reading a record, the record has to be read whole without
stopping, as a tape gap is needed to stop the tape motion without
losing information.

   Using higher blocking (putting more disk blocks per tape block) will
use the tape more efficiently as there will be less tape gaps.  But
reading such tapes may be more difficult for the system, as more memory
will be required to receive at once the whole record.  Further, if
there is a reading error on a huge record, this is less likely that the
system will succeed in recovering the information.  So, blocking should
not be too low, nor it should be too high.  `tar' uses by default a
blocking of 20 for historical reasons, and it does not really matter
when reading or writing to disk.  Current tape technology would easily
accomodate higher blockings.  Sun recommends a blocking of 126 for
Exabytes and 96 for DATs.  We were told that for some DLT drives, the
blocking should be a multiple of 4Kb, preferably 64Kb (`-b 128' or
`256') for decent performance.  Other manufacturers may use different
recommendations for the same tapes.  This might also depend of the
buffering techniques used inside modern tape controllers.  Some impose
a minimum blocking, or a maximum blocking.  Others request blocking to
be some exponent of two.

   So, there is no fixed rule for blocking.  But blocking at read time
should ideally be the same as blocking used at write time.  At one place
I know, with a wide variety of equipment, they found it best to use a
blocking of 32 to guarantee that their tapes are fully interchangeable.

   I was also told that, for recycled tapes, prior erasure (by the same
drive unit that will be used to create the archives) sometimes lowers
the error rates observed at rewriting time.

   I might also use `--number-blocks' instead of `--block-number', so
`--block' will then expand to `--blocking-factor' unambiguously.


File: tar.info,  Node: Many,  Next: Using Multiple Tapes,  Prev: Blocking,  Up: Media

Many Archives on One Tape
=========================

   Most tape devices have two entries in the `/dev' directory, or
entries that come in pairs, which differ only in the minor number for
this device.  Let's take for example `/dev/tape', which often points to
the only or usual tape device of a given system.  There might be a
corresponding `/dev/nrtape' or `/dev/ntape'.  The simpler name is the
*rewinding* version of the device, while the name having `nr' in it is
the *no rewinding* version of the same device.

   A rewinding tape device will bring back the tape to its beginning
point automatically when this device is opened or closed.  Since `tar'
opens the archive file before using it and closes it afterwards, this
means that a simple:

     $ tar cf /dev/tape DIRECTORY

will reposition the tape to its beginning both prior and after saving
DIRECTORY contents to it, thus erasing prior tape contents and making
it so that any subsequent write subcommand will destroy what has just
been saved.

   So, a rewinding device is normally meant to hold one and only one
file.  If you want to put more than one `tar' archive on a given tape,
you will need to avoid using the rewinding version of the tape device.
You will also have to pay special attention to tape positioning.
Errors in positionning may overwrite the valuable data already on your
tape.  Many people, burnt by past experiences, will only use rewinding
devices and limit themselves to one file per tape, precisely to avoid
the risk of such errors.  Be fully aware that writing at the wrong
position on a tape loses all information past this point and most
probably until the end of the tape, and this destroyed information
*cannot* be recovered.

   To save DIRECTORY-1 as a first archive at the beginning of a tape,
and leave that tape ready for a second archive, you should use the
*non-rewinding* tape device:

     $ mt -f /dev/nrtape rewind
     $ tar cf /dev/nrtape DIRECTORY-1

   "Tape marks" are special magnetic patterns written on the tape
media, which are later recognizable by the reading hardware.  These
marks are used after each file, when there are many on a single tape.
An empty file (that is to say, two tape marks in a row) signal the
logical end of the tape, after which no files exist.  Usually,
non-rewinding tape device drivers will react to the close request issued
by `tar' by first writing two tape marks after your archive, and by
backspacing over one of these.  So, if you remove the tape at that time
from the tape drive, it is properly terminated.  But if you write
another file at the current position, the second tape mark will be
erased by the new information, leaving only one tape mark between files.

   So, you may now save DIRECTORY-2 as a second archive after the first
on the same non-rewinding tape by issuing the command:

     $ tar cf /dev/nrtape DIRECTORY-2

and so on for all the archives you want to put on the same tape.

   Another usual case is that you do not write all the archives the same
day, and you need to remove and store the tape between two archive
sessions.  In general, you must remember how many files are already
saved on your tape.  Suppose your tape already has 16 files on it, and
that you are ready to write the 17th.  You have to take care of skipping
the first 16 tape marks before saving DIRECTORY-17, say, by using these
commands:

     $ mt -f /dev/nrtape rewind
     $ mt -f /dev/nrtape fsf 16
     $ tar cf /dev/nrtape DIRECTORY-17

   In all the previous examples, we put aside blocking considerations,
but you should do the proper things for that as well.  *Note Blocking::.

* Menu:

* Tape Positioning::            Tape Positions and Tape Marks
* mt::                          The `mt' Utility


File: tar.info,  Node: Tape Positioning,  Next: mt,  Prev: Many,  Up: Many

Tape Positions and Tape Marks
-----------------------------

     *(This message will disappear, once this node revised.)*

   Just as archives can store more than one file from the file system,
tapes can store more than one archive file.  To keep track of where
archive files (or any other type of file stored on tape) begin and end,
tape archive devices write magnetic "tape marks" on the archive media.
Tape drives write one tape mark between files, two at the end of all
the file entries.

   If you think of data as a series of records "rrrr"'s, and tape marks
as "*"'s, a tape might look like the following:

     rrrr*rrrrrr*rrrrr*rr*rrrrr**-------------------------

   Tape devices read and write tapes using a read/write "tape head"--a
physical part of the device which can only access one point on the tape
at a time.  When you use `tar' to read or write archive data from a
tape device, the device will begin reading or writing from wherever on
the tape the tape head happens to be, regardless of which archive or
what part of the archive the tape head is on.  Before writing an
archive, you should make sure that no data on the tape will be
overwritten (unless it is no longer needed).  Before reading an
archive, you should make sure the tape head is at the beginning of the
archive you want to read.  (The `restore' script will find the archive
automatically.    .)  *Note mt::, for an explanation of the tape moving
utility.

   If you want to add new archive file entries to a tape, you should
advance the tape to the end of the existing file entries, backspace
over the last tape mark, and write the new archive file.  If you were
to add two archives to the example above, the tape might look like the
following:

     rrrr*rrrrrr*rrrrr*rr*rrrrr*rrr*rrrr**----------------


File: tar.info,  Node: mt,  Prev: Tape Positioning,  Up: Many

The `mt' Utility
----------------

     *(This message will disappear, once this node revised.)*

   *Note Blocking Factor::.

   You can use the `mt' utility to advance or rewind a tape past a
specified number of archive files on the tape.  This will allow you to
move to the beginning of an archive before extracting or reading it, or
to the end of all the archives before writing a new one.

   The syntax of the `mt' command is:

     mt [-f TAPENAME] OPERATION [NUMBER]

   where TAPENAME is the name of the tape device, NUMBER is the number
of times a subcommand is performed (with a default of one), and
OPERATION is one of the following:

`eof'
`weof'
     Writes NUMBER tape marks at the current position on the tape.

`fsf'
     Moves tape position forward NUMBER files.

`bsf'
     Moves tape position back NUMBER files.

`rewind'
     Rewinds the tape. (Ignores NUMBER).

`offline'
`rewoff1'
     Rewinds the tape and takes the tape device off-line. (Ignores
     NUMBER).

`status'
     Prints status information about the tape unit.

   If you don't specify a TAPENAME, `mt' uses the environment variable
`TAPE'; if `TAPE' is not defined, `mt' uses the device `/dev/rmt12'.

   `mt' returns a 0 exit status when the operation(s) were successful,
1 if the command was unrecognized, and 2 if a subcommand failed.

   If you use `--extract' (`--get', `-x') with the
`--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') option specified, `tar'
will read an archive label (the tape head has to be positioned on it)
and print an error if the archive label doesn't match the ARCHIVE-NAME
specified.  ARCHIVE-NAME can be any regular expression.  If the labels
match, `tar' extracts the archive.  *Note label::, .  `tar --list
--label' will cause `tar' to print the label.


File: tar.info,  Node: Using Multiple Tapes,  Next: label,  Prev: Many,  Up: Media

Using Multiple Tapes
====================

     *(This message will disappear, once this node revised.)*

   Often you might want to write a large archive, one larger than will
fit on the actual tape you are using.  In such a case, you can run
multiple `tar' commands, but this can be inconvenient, particularly if
you are using options like `--exclude=PATTERN' or dumping entire
filesystems.  Therefore, `tar' supports multiple tapes automatically.

   Use `--multi-volume' (`-M') on the command line, and then `tar' will,
when it reaches the end of the tape, prompt for another tape, and
continue the archive.  Each tape will have an independent archive, and
can be read without needing the other.  (As an exception to this, the
file that `tar' was archiving when it ran out of tape will usually be
split between the two archives; in this case you need to extract from
the first archive, using `--multi-volume' (`-M'), and then put in the
second tape when prompted, so `tar' can restore both halves of the
file.)

   GNU `tar' multi-volume archives do not use a truly portable format.
You need GNU `tar' at both end to process them properly.

   When prompting for a new tape, `tar' accepts any of the following
responses:

`?'
     Request `tar' to explain possible responses

`q'
     Request `tar' to exit immediately.

`n FILE NAME'
     Request `tar' to write the next volume on the file FILE NAME.

`!'
     Request `tar' to run a subshell.

`y'
     Request `tar' to begin writing the next volume.

   (You should type `y' only *after* you have changed the tape;
otherwise `tar' will write over the volume it just finished.)

   If you want more elaborate behavior than this, give `tar' the
`--info-script=SCRIPT-NAME' (`--new-volume-script=SCRIPT-NAME', `-F
SCRIPT-NAME') option.  The file SCRIPT-NAME is expected to be a program
(or shell script) to be run instead of the normal prompting procedure.
When the program finishes, `tar' will immediately begin writing the
next volume.  The behavior of the `n' response to the normal
tape-change prompt is not available if you use
`--info-script=SCRIPT-NAME' (`--new-volume-script=SCRIPT-NAME', `-F
SCRIPT-NAME').

   The method `tar' uses to detect end of tape is not perfect, and
fails on some operating systems or on some devices.  You can use the
`--tape-length=KBYTES' (`-L KBYTES') option if `tar' can't detect the
end of the tape itself.  This option selects `--multi-volume' (`-M')
automatically.  The SIZE argument should then be the usable size of the
tape.  But for many devices, and floppy disks in particular, this
option is never required for real, as far as we know.

   The volume number used by `tar' in its tape-change prompt can be
changed; if you give the `--volno-file=FILE-OF-NUMBER' option, then
FILE-OF-NUMBER should be an unexisting file to be created, or else, a
file already containing a decimal number.  That number will be used as
the volume number of the first volume written.  When `tar' is finished,
it will rewrite the file with the now-current volume number.  (This
does not change the volume number written on a tape label, as per
*Note label::, it *only* affects the number used in the prompt.)

   If you want `tar' to cycle through a series of tape drives, then you
can use the `n' response to the tape-change prompt.  This is error
prone, however, and doesn't work at all with
`--info-script=SCRIPT-NAME' (`--new-volume-script=SCRIPT-NAME', `-F
SCRIPT-NAME').  Therefore, if you give `tar' multiple
`--file=ARCHIVE-NAME' (`-f ARCHIVE-NAME') options, then the specified
files will be used, in sequence, as the successive volumes of the
archive.  Only when the first one in the sequence needs to be used
again will `tar' prompt for a tape change (or run the info script).

   Multi-volume archives

   With `--multi-volume' (`-M'), `tar' will not abort when it cannot
read or write any more data.  Instead, it will ask you to prepare a new
volume.  If the archive is on a magnetic tape, you should change tapes
now; if the archive is on a floppy disk, you should change disks, etc.

   Each volume of a multi-volume archive is an independent `tar'
archive, complete in itself.  For example, you can list or extract any
volume alone; just don't specify `--multi-volume' (`-M').  However, if
one file in the archive is split across volumes, the only way to extract
it successfully is with a multi-volume extract command `--extract
--multi-volume' (`-xM') starting on or before the volume where the file
begins.

   For example, let's presume someone has two tape drives on a system
named `/dev/tape0' and `/dev/tape1'.  For having GNU `tar' to switch to
the second drive when it needs to write the second tape, and then back
to the first tape, etc., just do either of:

     $ tar --create --multi-volume --file=/dev/tape0 --file=/dev/tape1 FILES
     $ tar cMff /dev/tape0 /dev/tape1 FILES

* Menu:

* Multi-Volume Archives::       Archives Longer than One Tape or Disk
* Tape Files::                  Tape Files

