tar.info-2 [plain text]

This is tar.info, produced by makeinfo version 4.7.90 from tar.texi.

This manual is for GNU `tar' (version 1.14.90, 4 October 2004),
which creates and extracts files from archives.

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software
Foundation; with the Invariant Sections being "GNU General Public
License", with the Front-Cover Texts being "A GNU Manual," and
with the Back-Cover Texts as in (a) below. A copy of the license
is included in the section entitled "GNU Free Documentation
License".

(a) The FSF's Back-Cover Text is: "You are free to copy and modify
this GNU Manual. Buying copies from GNU Press supports the FSF in
developing GNU and promoting software freedom."

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

INFO-DIR-SECTION Individual utilities
START-INFO-DIR-ENTRY
* tar: (tar)tar invocation. Invoking GNU `tar'.
END-INFO-DIR-ENTRY

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

8.6 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.

If anyone knows 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 resyncing.
However, 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: Free Software Needs Free Documentation, Prev: Formats, Up: Top

9 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 formatted 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, Up: Media

9.1 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 `/usr/libexec/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
`/usr/libexec/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. The exact
path to this utility is determined when configuring the package. It is
`PREFIX/libexec/rmt', where PREFIX stands for your installation prefix.
This location may also be overridden at runtime by using
`rmt-command=COMMAND' option (*Note --rmt-command: Option Summary, for
detailed description of this option. *Note Remote Tape Server::, for
the description of `rmt' command).

If this option 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 too many cases, it was hopeless. This is now
completely left to the installer to override standard input and
standard output for default device, if this seems preferable. 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'
Archive file is local even if it contains a colon.

`--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 command 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
overridden this by defining the environment variable `RSH' _at
installation time_.

`-[0-7][lmh]'
Specify drive and density.

`-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. If `file' exits with nonzero
status, exit. This implies `--multi-volume' (`-M').

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

9.2 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 `PREFIX/libexec/rmt' on
any machine whose tape drive you want to use. `tar' calls `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. It is compiled and installed by default.

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.
It will also type a warning message telling you what it is doing.

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. 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.

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 / ...'.

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

9.3 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

9.4 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' ignore 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 mean 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 to speak of 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=512-SIZE' (`-b 512-SIZE') 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=512-SIZE' (`-b 512-SIZE')) larger than the actual
blocking factor, and then use the `--read-full-records' (`-B') option.
(If you specify a blocking factor with `--blocking-factor=512-SIZE'
(`-b 512-SIZE') 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=512-SIZE' (`-b 512-SIZE') 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=512-SIZE' (`-b 512-SIZE') 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, Up: Blocking

9.4.1 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=512-SIZE' (`-b 512-SIZE') 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

9.4.2 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=512-SIZE' (`-b 512-SIZE') 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 useful 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') operation. *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
operation, 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 operations 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 disappear. 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=512-SIZE' (`-b 512-SIZE') is not
explicitly specified on the `tar' invocation.

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 concatenating 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
loosing 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
accommodate 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 depends of the
buffering techniques used inside modern tape controllers. Some imposes
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

9.5 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 operation 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 positioning 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:

$ 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 file 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 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, Up: Many

9.5.1 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

9.5.2 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 an operation 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 set, `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 an operation 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

9.6 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 only type `y' 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.
If the program fails, `tar' exits; otherwise, `tar' begins 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=1024-SIZE' (`-L 1024-SIZE') 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

File: tar.info, Node: Multi-Volume Archives, Next: Tape Files, Up: Using Multiple Tapes

9.6.1 Archives Longer than One Tape or Disk
-------------------------------------------

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

To create an archive that is larger than will fit on a single unit of
the media, use the `--multi-volume' (`-M') option in conjunction with
the `--create' (`-c') option (*note create::). A "multi-volume"
archive can be manipulated like any other archive (provided the
`--multi-volume' (`-M') option is specified), but is stored on more
than one tape or disk.

When you specify `--multi-volume' (`-M'), `tar' does not report an
error when it comes to the end of an archive volume (when reading), or
the end of the media (when writing). Instead, it prompts you to load a
new storage volume. If the archive is on a magnetic tape, you should
change tapes when you see the prompt; if the archive is on a floppy
disk, you should change disks; etc.

You can read each individual volume of a multi-volume archive as if
it were an archive by itself. For example, to list the contents of one
volume, use `--list' (`-t'), without `--multi-volume' (`-M') specified.
To extract an archive member from one volume (assuming it is described
that volume), use `--extract' (`--get', `-x'), again without
`--multi-volume' (`-M').

If an archive member is split across volumes (ie. its entry begins on
one volume of the media and ends on another), you need to specify
`--multi-volume' (`-M') to extract it successfully. In this case, you
should load the volume where the archive member starts, and use `tar
--extract --multi-volume'--`tar' will prompt for later volumes as it
needs them. *Note extracting archives::, for more information about
extracting archives.

`--info-script=SCRIPT-NAME' (`--new-volume-script=SCRIPT-NAME', `-F
SCRIPT-NAME') is like `--multi-volume' (`-M'), except that `tar' does
not prompt you directly to change media volumes when a volume is
full--instead, `tar' runs commands you have stored in SCRIPT-NAME. For
example, this option can be used to eject cassettes, or to broadcast
messages such as `Someone please come change my tape' when performing
unattended backups. When SCRIPT-NAME is done, `tar' will assume that
the media has been changed.

Multi-volume archives can be modified like any other archive. To add
files to a multi-volume archive, you need to only mount the last volume
of the archive media (and new volumes, if needed). For all other
operations, you need to use the entire archive.

If a multi-volume archive was labeled using `--label=ARCHIVE-LABEL'
(`-V ARCHIVE-LABEL') (*note label::) when it was created, `tar' will not
automatically label volumes which are added later. To label subsequent
volumes, specify `--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') again in
conjunction with the `--append' (`-r'), `--update' (`-u') or
`--concatenate' (`--catenate', `-A') operation.

`--multi-volume'
`-M'
Creates a multi-volume archive, when used in conjunction with
`--create' (`-c'). To perform any other operation on a
multi-volume archive, specify `--multi-volume' (`-M') in
conjunction with that operation.

`--info-script=PROGRAM-FILE'
`-F PROGRAM-FILE'
Creates a multi-volume archive via a script. Used in conjunction
with `--create' (`-c').

Beware that there is _no_ real standard about the proper way, for a
`tar' archive, to span volume boundaries. If you have a multi-volume
created by some vendor's `tar', there is almost no chance you could
read all the volumes with GNU `tar'. The converse is also true: you
may not expect multi-volume archives created by GNU `tar' to be fully
recovered by vendor's `tar'. Since there is little chance that, in
mixed system configurations, some vendor's `tar' will work on another
vendor's machine, and there is a great chance that GNU `tar' will work
on most of them, your best bet is to install GNU `tar' on all machines
between which you know exchange of files is possible.

File: tar.info, Node: Tape Files, Prev: Multi-Volume Archives, Up: Using Multiple Tapes

9.6.2 Tape Files
----------------

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

To give the archive a name which will be recorded in it, use the
`--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') option. This will write a
special block identifying VOLUME-LABEL as the name of the archive to
the front of the archive which will be displayed when the archive is
listed with `--list' (`-t'). If you are creating a multi-volume
archive with `--multi-volume' (`-M'), then the volume label will have
`Volume NNN' appended to the name you give, where NNN is the number of
the volume of the archive. (If you use the `--label=ARCHIVE-LABEL'
(`-V ARCHIVE-LABEL') option when reading an archive, it checks to make
sure the label on the tape matches the one you give. *Note label::.

When `tar' writes an archive to tape, it creates a single tape file.
If multiple archives are written to the same tape, one after the
other, they each get written as separate tape files. When extracting,
it is necessary to position the tape at the right place before running
`tar'. To do this, use the `mt' command. For more information on the
`mt' command and on the organization of tapes into a sequence of tape
files, see *Note mt::.

People seem to often do:

--label="SOME-PREFIX `date +SOME-FORMAT`"

or such, for pushing a common date in all volumes or an archive set.

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

9.7 Including a Label in the Archive
====================================

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

`-V NAME'
`--label=NAME'
Create archive with volume name NAME.

This option causes `tar' to write out a "volume header" at the
beginning of the archive. If `--multi-volume' (`-M') is used, each
volume of the archive will have a volume header of `NAME Volume N',
where N is 1 for the first volume, 2 for the next, and so on.

To avoid problems caused by misplaced paper labels on the archive
media, you can include a "label" entry--an archive member which
contains the name of the archive--in the archive itself. Use the
`--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') option in conjunction with
the `--create' (`-c') operation to include a label entry in the archive
as it is being created.

If you create an archive using both `--label=ARCHIVE-LABEL' (`-V
ARCHIVE-LABEL') and `--multi-volume' (`-M'), each volume of the archive
will have an archive label of the form `ARCHIVE-LABEL Volume N', where
N is 1 for the first volume, 2 for the next, and so on.

If you list or extract an archive using `--label=ARCHIVE-LABEL' (`-V
ARCHIVE-LABEL'), `tar' will print an error if the archive label doesn't
match the ARCHIVE-LABEL specified, and will then not list nor extract
the archive. In those cases, ARCHIVE-LABEL argument is interpreted as
a globbing-style pattern which must match the actual magnetic volume
label. *Note exclude::, for a precise description of how match is
attempted(1). If the switch `--multi-volume' (`-M') is being used, the
volume label matcher will also suffix ARCHIVE-LABEL by ` Volume [1-9]*'
if the initial match fails, before giving up. Since the volume
numbering is automatically added in labels at creation time, it sounded
logical to equally help the user taking care of it when the archive is
being read.

The `--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') was once called
`--volume', but is not available under that name anymore.

To find out an archive's label entry (or to find out if an archive
has a label at all), use `tar --list --verbose'. `tar' will print the
label first, and then print archive member information, as in the
example below:

$ tar --verbose --list --file=iamanarchive
V--------- 0 0 0 1992-03-07 12:01 iamalabel--Volume Header--
-rw-rw-rw- ringo user 40 1990-05-21 13:30 iamafilename

`--label=ARCHIVE-LABEL'
`-V ARCHIVE-LABEL'
Includes an "archive-label" at the beginning of the archive when
the archive is being created, when used in conjunction with the
`--create' (`-c') option. Checks to make sure the archive label
matches the one specified (when used in conjunction with the
`--extract' (`--get', `-x') option.

To get a common information on all tapes of a series, use the
`--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') option. For having this
information different in each series created through a single script
used on a regular basis, just manage to get some date string as part of
the label. For example:

$ tar cfMV /dev/tape "Daily backup for `date +%Y-%m-%d`"
$ tar --create --file=/dev/tape --multi-volume \
--volume="Daily backup for `date +%Y-%m-%d`"

Also note that each label has its own date and time, which
corresponds to when GNU `tar' initially attempted to write it, often
soon after the operator launches `tar' or types the carriage return
telling that the next tape is ready. Comparing date labels does give
an idea of tape throughput only if the delays for rewinding tapes and
the operator switching them were negligible, which is usually not the
case.

---------- Footnotes ----------

(1) Previous versions of `tar' used full regular expression
matching, or before that, only exact string matching, instead of
wildcard matchers. We decided for the sake of simplicity to use a
uniform matching device through `tar'.

File: tar.info, Node: verify, Next: Write Protection, Prev: label, Up: Media

9.8 Verifying Data as It is Stored
==================================

`-W'
`--verify'
Attempt to verify the archive after writing.

This option causes `tar' to verify the archive after writing it.
Each volume is checked after it is written, and any discrepancies are
recorded on the standard error output.

Verification requires that the archive be on a back-space-able
medium. This means pipes, some cartridge tape drives, and some other
devices cannot be verified.

You can insure the accuracy of an archive by comparing files in the
system with archive members. `tar' can compare an archive to the file
system as the archive is being written, to verify a write operation, or
can compare a previously written archive, to insure that it is up to
date.

To check for discrepancies in an archive immediately after it is
written, use the `--verify' (`-W') option in conjunction with the
`--create' (`-c') operation. When this option is specified, `tar'
checks archive members against their counterparts in the file system,
and reports discrepancies on the standard error.

To verify an archive, you must be able to read it from before the end
of the last written entry. This option is useful for detecting data
errors on some tapes. Archives written to pipes, some cartridge tape
drives, and some other devices cannot be verified.

One can explicitly compare an already made archive with the file
system by using the `--compare' (`--diff', `-d') option, instead of
using the more automatic `--verify' (`-W') option. *Note compare::.

Note that these two options have a slightly different intent. The
`--compare' (`--diff', `-d') option how identical are the logical
contents of some archive with what is on your disks, while the
`--verify' (`-W') option is really for checking if the physical
contents agree and if the recording media itself is of dependable
quality. So, for the `--verify' (`-W') operation, `tar' tries to
defeat all in-memory cache pertaining to the archive, while it lets the
speed optimization undisturbed for the `--compare' (`--diff', `-d')
option. If you nevertheless use `--compare' (`--diff', `-d') for media
verification, you may have to defeat the in-memory cache yourself,
maybe by opening and reclosing the door latch of your recording unit,
forcing some doubt in your operating system about the fact this is
really the same volume as the one just written or read.

The `--verify' (`-W') option would not be necessary if drivers were
indeed able to detect dependably all write failures. This sometimes
require many magnetic heads, some able to read after the writes
occurred. One would not say that drivers unable to detect all cases
are necessarily flawed, as long as programming is concerned.

The `--verify' (`-W') option will not work in conjunction with the
`--multi-volume' (`-M') option or the `--append' (`-r'), `--update'
(`-u') and `--delete' operations. *Note Operations::, for more
information on these operations.

Also, since `tar' normally strips leading `/' from file names (*note
absolute::), a command like `tar --verify -cf /tmp/foo.tar /etc' will
work as desired only if the working directory is `/', as `tar' uses the
archive's relative member names (e.g., `etc/motd') when verifying the
archive.

File: tar.info, Node: Write Protection, Prev: verify, Up: Media

9.9 Write Protection
====================

Almost all tapes and diskettes, and in a few rare cases, even disks can
be "write protected", to protect data on them from being changed. Once
an archive is written, you should write protect the media to prevent
the archive from being accidentally overwritten or deleted. (This will
protect the archive from being changed with a tape or floppy drive--it
will not protect it from magnet fields or other physical hazards).

The write protection device itself is usually an integral part of the
physical media, and can be a two position (write enabled/write
disabled) switch, a notch which can be popped out or covered, a ring
which can be removed from the center of a tape reel, or some other
changeable feature.

File: tar.info, Node: Free Software Needs Free Documentation, Next: Copying This Manual, Prev: Media, Up: Top

Appendix A Free Software Needs Free Documentation
*************************************************

The biggest deficiency in the free software community today is not in
the software--it is the lack of good free documentation that we can
include with the free software. Many of our most important programs do
not come with free reference manuals and free introductory texts.
Documentation is an essential part of any software package; when an
important free software package does not come with a free manual and a
free tutorial, that is a major gap. We have many such gaps today.

Consider Perl, for instance. The tutorial manuals that people
normally use are non-free. How did this come about? Because the
authors of those manuals published them with restrictive terms--no
copying, no modification, source files not available--which exclude
them from the free software world.

That wasn't the first time this sort of thing happened, and it was
far from the last. Many times we have heard a GNU user eagerly
describe a manual that he is writing, his intended contribution to the
community, only to learn that he had ruined everything by signing a
publication contract to make it non-free.

Free documentation, like free software, is a matter of freedom, not
price. The problem with the non-free manual is not that publishers
charge a price for printed copies--that in itself is fine. (The Free
Software Foundation sells printed copies of manuals, too.) The problem
is the restrictions on the use of the manual. Free manuals are
available in source code form, and give you permission to copy and
modify. Non-free manuals do not allow this.

The criteria of freedom for a free manual are roughly the same as for
free software. Redistribution (including the normal kinds of
commercial redistribution) must be permitted, so that the manual can
accompany every copy of the program, both on-line and on paper.

Permission for modification of the technical content is crucial too.
When people modify the software, adding or changing features, if they
are conscientious they will change the manual too--so they can provide
accurate and clear documentation for the modified program. A manual
that leaves you no choice but to write a new manual to document a
changed version of the program is not really available to our community.

Some kinds of limits on the way modification is handled are
acceptable. For example, requirements to preserve the original
author's copyright notice, the distribution terms, or the list of
authors, are ok. It is also no problem to require modified versions to
include notice that they were modified. Even entire sections that may
not be deleted or changed are acceptable, as long as they deal with
nontechnical topics (like this one). These kinds of restrictions are
acceptable because they don't obstruct the community's normal use of
the manual.

However, it must be possible to modify all the _technical_ content
of the manual, and then distribute the result in all the usual media,
through all the usual channels. Otherwise, the restrictions obstruct
the use of the manual, it is not free, and we need another manual to
replace it.

Please spread the word about this issue. Our community continues to
lose manuals to proprietary publishing. If we spread the word that
free software needs free reference manuals and free tutorials, perhaps
the next person who wants to contribute by writing documentation will
realize, before it is too late, that only free manuals contribute to
the free software community.

If you are writing documentation, please insist on publishing it
under the GNU Free Documentation License or another free documentation
license. Remember that this decision requires your approval--you don't
have to let the publisher decide. Some commercial publishers will use
a free license if you insist, but they will not propose the option; it
is up to you to raise the issue and say firmly that this is what you
want. If the publisher you are dealing with refuses, please try other
publishers. If you're not sure whether a proposed license is free,
write to <licensing@gnu.org>.

You can encourage commercial publishers to sell more free, copylefted
manuals and tutorials by buying them, and particularly by buying copies
from the publishers that paid for their writing or for major
improvements. Meanwhile, try to avoid buying non-free documentation at
all. Check the distribution terms of a manual before you buy it, and
insist that whoever seeks your business must respect your freedom.
Check the history of the book, and try reward the publishers that have
paid or pay the authors to work on it.

The Free Software Foundation maintains a list of free documentation
published by other publishers, at
`http://www.fsf.org/doc/other-free-books.html'.

File: tar.info, Node: Copying This Manual, Next: Index, Prev: Free Software Needs Free Documentation, Up: Top

Appendix B Copying This Manual
******************************

* Menu:

* GNU Free Documentation License:: License for copying this manual

File: tar.info, Node: GNU Free Documentation License, Up: Copying This Manual

B.1 GNU Free Documentation License
==================================

Version 1.2, November 2002

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or
noncommercially. Secondarily, this License preserves for the
author and publisher a way to get credit for their work, while not
being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.
It complements the GNU General Public License, which is a copyleft
license designed for free software.

We have designed this License in order to use it for manuals for
free software, because free software needs free documentation: a
free program should come with manuals providing the same freedoms
that the software does. But this License is not limited to
software manuals; it can be used for any textual work, regardless
of subject matter or whether it is published as a printed book.
We recommend this License principally for works whose purpose is
instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium,
that contains a notice placed by the copyright holder saying it
can be distributed under the terms of this License. Such a notice
grants a world-wide, royalty-free license, unlimited in duration,
to use that work under the conditions stated herein. The
"Document", below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as "you". You
accept the license if you copy, modify or distribute the work in a
way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section
of the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall
subject (or to related matters) and contains nothing that could
fall directly within that overall subject. (Thus, if the Document
is in part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter of
historical connection with the subject or with related matters, or
of legal, commercial, philosophical, ethical or political position
regarding them.

The "Invariant Sections" are certain Secondary Sections whose
titles are designated, as being those of Invariant Sections, in
the notice that says that the Document is released under this
License. If a section does not fit the above definition of
Secondary then it is not allowed to be designated as Invariant.
The Document may contain zero Invariant Sections. If the Document
does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
that says that the Document is released under this License. A
Front-Cover Text may be at most 5 words, and a Back-Cover Text may
be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images
composed of pixels) generic paint programs or (for drawings) some
widely available drawing editor, and that is suitable for input to
text formatters or for automatic translation to a variety of
formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup, or absence of
markup, has been arranged to thwart or discourage subsequent
modification by readers is not Transparent. An image format is
not Transparent if used for any substantial amount of text. A
copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format,
SGML or XML using a publicly available DTD, and
standard-conforming simple HTML, PostScript or PDF designed for
human modification. Examples of transparent image formats include
PNG, XCF and JPG. Opaque formats include proprietary formats that
can be read and edited only by proprietary word processors, SGML or
XML for which the DTD and/or processing tools are not generally
available, and the machine-generated HTML, PostScript or PDF
produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the
material this License requires to appear in the title page. For
works in formats which do not have any title page as such, "Title
Page" means the text near the most prominent appearance of the
work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document
whose title either is precisely XYZ or contains XYZ in parentheses
following text that translates XYZ in another language. (Here XYZ
stands for a specific section name mentioned below, such as
"Acknowledgements", "Dedications", "Endorsements", or "History".)
To "Preserve the Title" of such a section when you modify the
Document means that it remains a section "Entitled XYZ" according
to this definition.

The Document may include Warranty Disclaimers next to the notice
which states that this License applies to the Document. These
Warranty Disclaimers are considered to be included by reference in
this License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and
has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that you
add no other conditions whatsoever to those of this License. You
may not use technical measures to obstruct or control the reading
or further copying of the copies you make or distribute. However,
you may accept compensation in exchange for copies. If you
distribute a large enough number of copies you must also follow
the conditions in section 3.

You may also lend copies, under the same conditions stated above,
and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly
have printed covers) of the Document, numbering more than 100, and
the Document's license notice requires Cover Texts, you must
enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and
Back-Cover Texts on the back cover. Both covers must also clearly
and legibly identify you as the publisher of these copies. The
front cover must present the full title with all words of the
title equally prominent and visible. You may add other material
on the covers in addition. Copying with changes limited to the
covers, as long as they preserve the title of the Document and
satisfy these conditions, can be treated as verbatim copying in
other respects.

If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto
adjacent pages.

If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a
machine-readable Transparent copy along with each Opaque copy, or
state in or with each Opaque copy a computer-network location from
which the general network-using public has access to download
using public-standard network protocols a complete Transparent
copy of the Document, free of added material. If you use the
latter option, you must take reasonably prudent steps, when you
begin distribution of Opaque copies in quantity, to ensure that
this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you
distribute an Opaque copy (directly or through your agents or
retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of
the Document well before redistributing any large number of
copies, to give them a chance to provide you with an updated
version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document
under the conditions of sections 2 and 3 above, provided that you
release the Modified Version under precisely this License, with
the Modified Version filling the role of the Document, thus
licensing distribution and modification of the Modified Version to
whoever possesses a copy of it. In addition, you must do these
things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title
distinct from that of the Document, and from those of
previous versions (which should, if there were any, be listed
in the History section of the Document). You may use the
same title as a previous version if the original publisher of
that version gives permission.

B. List on the Title Page, as authors, one or more persons or
entities responsible for authorship of the modifications in
the Modified Version, together with at least five of the
principal authors of the Document (all of its principal
authors, if it has fewer than five), unless they release you
from this requirement.

C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license
notice giving the public permission to use the Modified
Version under the terms of this License, in the form shown in
the Addendum below.

G. Preserve in that license notice the full lists of Invariant
Sections and required Cover Texts given in the Document's
license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled "History", Preserve its Title,
and add to it an item stating at least the title, year, new
authors, and publisher of the Modified Version as given on
the Title Page. If there is no section Entitled "History" in
the Document, create one stating the title, year, authors,
and publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as stated in
the previous sentence.

J. Preserve the network location, if any, given in the Document
for public access to a Transparent copy of the Document, and
likewise the network locations given in the Document for
previous versions it was based on. These may be placed in
the "History" section. You may omit a network location for a
work that was published at least four years before the
Document itself, or if the original publisher of the version
it refers to gives permission.

K. For any section Entitled "Acknowledgements" or "Dedications",
Preserve the Title of the section, and preserve in the
section all the substance and tone of each of the contributor
acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section
titles.

M. Delete any section Entitled "Endorsements". Such a section
may not be included in the Modified Version.

N. Do not retitle any existing section to be Entitled
"Endorsements" or to conflict in title with any Invariant
Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no
material copied from the Document, you may at your option
designate some or all of these sections as invariant. To do this,
add their titles to the list of Invariant Sections in the Modified
Version's license notice. These titles must be distinct from any
other section titles.

You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text
has been approved by an organization as the authoritative
definition of a standard.

You may add a passage of up to five words as a Front-Cover Text,
and a passage of up to 25 words as a Back-Cover Text, to the end
of the list of Cover Texts in the Modified Version. Only one
passage of Front-Cover Text and one of Back-Cover Text may be
added by (or through arrangements made by) any one entity. If the
Document already includes a cover text for the same cover,
previously added by you or by arrangement made by the same entity
you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous
publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this
License give permission to use their names for publicity for or to
assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under
this License, under the terms defined in section 4 above for
modified versions, provided that you include in the combination
all of the Invariant Sections of all of the original documents,
unmodified, and list them all as Invariant Sections of your
combined work in its license notice, and that you preserve all
their Warranty Disclaimers.

The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name
but different contents, make the title of each such section unique
by adding at the end of it, in parentheses, the name of the
original author or publisher of that section if known, or else a
unique number. Make the same adjustment to the section titles in
the list of Invariant Sections in the license notice of the
combined work.

In the combination, you must combine any sections Entitled
"History" in the various original documents, forming one section
Entitled "History"; likewise combine any sections Entitled
"Acknowledgements", and any sections Entitled "Dedications". You
must delete all sections Entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other
documents released under this License, and replace the individual
copies of this License in the various documents with a single copy
that is included in the collection, provided that you follow the
rules of this License for verbatim copying of each of the
documents in all other respects.

You may extract a single document from such a collection, and
distribute it individually under this License, provided you insert
a copy of this License into the extracted document, and follow
this License in all other respects regarding verbatim copying of
that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other
separate and independent documents or works, in or on a volume of
a storage or distribution medium, is called an "aggregate" if the
copyright resulting from the compilation is not used to limit the
legal rights of the compilation's users beyond what the individual
works permit. When the Document is included in an aggregate, this
License does not apply to the other works in the aggregate which
are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half
of the entire aggregate, the Document's Cover Texts may be placed
on covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic
form. Otherwise they must appear on printed covers that bracket
the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section
4. Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also
include the original English version of this License and the
original versions of those notices and disclaimers. In case of a
disagreement between the translation and the original version of
this License or a notice or disclaimer, the original version will
prevail.

If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to
Preserve its Title (section 1) will typically require changing the
actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document
except as expressly provided for under this License. Any other
attempt to copy, modify, sublicense or distribute the Document is
void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights,
from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of
the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
`http://www.gnu.org/copyleft/'.

Each version of the License is given a distinguishing version
number. If the Document specifies that a particular numbered
version of this License "or any later version" applies to it, you
have the option of following the terms and conditions either of
that specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If
the Document does not specify a version number of this License,
you may choose any version ever published (not as a draft) by the
Free Software Foundation.

B.1.1 ADDENDUM: How to use this License for your documents
----------------------------------------------------------

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

Copyright (C) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled ``GNU
Free Documentation License''.

If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:

with the Invariant Sections being LIST THEIR TITLES, with
the Front-Cover Texts being LIST, and with the Back-Cover Texts
being LIST.

If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.

File: tar.info, Node: Index, Prev: Copying This Manual, Up: Top

Appendix C Index
****************

[index]
* Menu:

* --list with file name arguments: list. (line 40)
* -backup: backup. (line 41)
* -suffix: backup. (line 68)
* abbreviations for months: Calendar date items. (line 38)
* absolute file names: Remote Tape Server. (line 17)
* Adding archives to an archive: concatenate. (line 6)
* Adding files to an Archive: appending files. (line 8)
* ADMINISTRATOR: General-Purpose Variables.
(line 7)
* Age, excluding files by: after. (line 6)
* ago in date strings: Relative items in date strings.
(line 23)
* am in date strings: Time of day items. (line 21)
* Appending files to an Archive: appending files. (line 8)
* archive: Definitions. (line 6)
* Archive creation: file. (line 36)
* archive member: Definitions. (line 15)
* Archive Name: file. (line 6)
* Archives, Appending files to: appending files. (line 8)
* Archiving Directories: create dir. (line 6)
* archiving files: Top. (line 25)
* authors of get_date: Authors of get_date. (line 6)
* Avoiding recursion in directories: recurse. (line 6)
* backup options: backup. (line 6)
* backup suffix: backup. (line 68)
* BACKUP_DIRS: General-Purpose Variables.
(line 27)
* BACKUP_FILES: General-Purpose Variables.
(line 53)
* BACKUP_HOUR: General-Purpose Variables.
(line 11)
* backups: backup. (line 41)
* beginning of time, for POSIX: Seconds since the Epoch.
(line 11)
* Bellovin, Steven M.: Authors of get_date. (line 6)
* Berets, Jim: Authors of get_date. (line 6)
* Berry, K.: Authors of get_date. (line 14)
* Block number where error occurred: verbose. (line 6)
* BLOCKING: General-Purpose Variables.
(line 23)
* blocking factor: Blocking Factor. (line 194)
* Blocking Factor: Blocking Factor. (line 6)
* Blocks per record: Blocking Factor. (line 6)
* bug reports: Reports. (line 6)
* Bytes per record: Blocking Factor. (line 6)
* calendar date item: Calendar date items. (line 6)
* case, ignored in dates: General date syntax. (line 61)
* cat vs concatenate: concatenate. (line 60)
* Changing directory mid-stream: directory. (line 6)
* Character class, excluding characters from: Wildcards. (line 34)
* Choosing an archive file: file. (line 6)
* comments, in dates: General date syntax. (line 61)
* Compressed archives: gzip. (line 6)
* concatenate vs cat: concatenate. (line 60)
* Concatenating Archives: concatenate. (line 6)
* corrupted archives <1>: gzip. (line 51)
* corrupted archives: Full Dumps. (line 8)
* DAT blocking: Blocking Factor. (line 204)
* date format, ISO 8601: Calendar date items. (line 30)
* date input formats: Date input formats. (line 6)
* day in date strings: Relative items in date strings.
(line 15)
* day of week item: Day of week items. (line 6)
* Deleting files from an archive: delete. (line 8)
* Deleting from tape archives: delete. (line 20)
* Descending directories, avoiding: recurse. (line 6)
* Directing output: file. (line 6)
* Directories, Archiving: create dir. (line 6)
* Directories, avoiding recursion: recurse. (line 6)
* Directory, changing mid-stream: directory. (line 6)
* DIRLIST: General-Purpose Variables.
(line 49)
* Disk space, running out of: Scarce. (line 6)
* displacement of dates: Relative items in date strings.
(line 6)
* Double-checking a write operation: verify. (line 6)
* DUMP_BEGIN: User Hooks. (line 32)
* DUMP_END: User Hooks. (line 35)
* DUMP_REMIND_SCRIPT: General-Purpose Variables.
(line 95)
* dumps, full: Full Dumps. (line 8)
* dumps, incremental: Inc Dumps. (line 8)
* Eggert, Paul: Authors of get_date. (line 6)
* End-of-archive entries, ignoring: Reading. (line 6)
* entry: Naming tar Archives. (line 11)
* epoch, for POSIX: Seconds since the Epoch.
(line 11)
* Error message, block number of: verbose. (line 6)
* Exabyte blocking: Blocking Factor. (line 204)
* exclude: exclude. (line 15)
* exclude-caches: exclude. (line 38)
* exclude-from: exclude. (line 28)
* Excluding characters from a character class: Wildcards. (line 34)
* Excluding file by age: after. (line 6)
* Excluding files by file system: exclude. (line 6)
* Excluding files by name and pattern: exclude. (line 6)
* existing backup method: backup. (line 59)
* exit status: Synopsis. (line 67)
* Extraction: extract. (line 8)
* extraction: Definitions. (line 22)
* FDL, GNU Free Documentation License: GNU Free Documentation License.
(line 6)
* Feedback from tar: verbose. (line 6)
* file archival: Top. (line 25)
* file name: Definitions. (line 15)
* File Name arguments, alternatives: files. (line 8)
* File name arguments, using --list with: list. (line 40)
* File names, excluding files by: exclude. (line 6)
* File names, terminated by NUL: nul. (line 6)
* File names, using symbolic links: dereference. (line 6)
* File system boundaries, not crossing: one. (line 6)
* FILELIST: General-Purpose Variables.
(line 63)
* first in date strings: General date syntax. (line 26)
* Format Options: Format Variations. (line 6)
* Format Parameters: Format Variations. (line 6)
* Format, old style: old. (line 6)
* fortnight in date strings: Relative items in date strings.
(line 15)
* free documentation: Free Software Needs Free Documentation.
(line 6)
* full dumps: Full Dumps. (line 8)
* future time stamps: Large or Negative Values.
(line 6)
* general date syntax: General date syntax. (line 6)
* get_date: Date input formats. (line 6)
* Getting more information during the operation: verbose. (line 6)
* hook: User Hooks. (line 13)
* hour in date strings: Relative items in date strings.
(line 15)
* Ignoring end-of-archive entries: Reading. (line 6)
* incremental dumps: Inc Dumps. (line 8)
* Information during operation: verbose. (line 6)
* Information on progress and status of operations: verbose. (line 6)
* Interactive operation: interactive. (line 6)
* ISO 8601 date format: Calendar date items. (line 30)
* items in date strings: General date syntax. (line 6)
* Labeling an archive: label. (line 6)
* Labeling multi-volume archives: Multi-Volume Archives.
(line 58)
* Labels on the archive media: label. (line 6)
* language, in dates: General date syntax. (line 37)
* Large lists of file names on small machines: Reading. (line 6)
* large values: Large or Negative Values.
(line 6)
* last DAY: Day of week items. (line 15)
* last in date strings: General date syntax. (line 26)
* Lists of file names: files. (line 8)
* MacKenzie, David: Authors of get_date. (line 6)
* member: Definitions. (line 15)
* member name: Definitions. (line 15)
* Members, replacing with other members: append. (line 49)
* Meyering, Jim: Authors of get_date. (line 6)
* Middle of the archive, starting in the: Scarce. (line 6)
* midnight in date strings: Time of day items. (line 21)
* minute in date strings: Relative items in date strings.
(line 15)
* minutes, time zone correction by: Time of day items. (line 29)
* Modes of extracted files: Writing. (line 6)
* Modification time, excluding files by: after. (line 6)
* Modification times of extracted files: Writing. (line 6)
* month in date strings: Relative items in date strings.
(line 15)
* month names in date strings: Calendar date items. (line 38)
* months, written-out: General date syntax. (line 33)
* MT_BEGIN: Magnetic Tape Control.
(line 11)
* MT_OFFLINE: Magnetic Tape Control.
(line 32)
* MT_REWIND: Magnetic Tape Control.
(line 21)
* MT_STATUS: Magnetic Tape Control.
(line 42)
* Multi-volume archives: Multi-Volume Archives.
(line 6)
* Naming an archive: file. (line 6)
* negative time stamps: Large or Negative Values.
(line 6)
* next DAY: Day of week items. (line 15)
* next in date strings: General date syntax. (line 26)
* noon in date strings: Time of day items. (line 21)
* now in date strings: Relative items in date strings.
(line 33)
* ntape device: Many. (line 6)
* NUL terminated file names: nul. (line 6)
* Number of blocks per record: Blocking Factor. (line 6)
* Number of bytes per record: Blocking Factor. (line 6)
* numbered backup method: backup. (line 55)
* numbers, written-out: General date syntax. (line 26)
* Old style archives: old. (line 6)
* Old style format: old. (line 6)
* option syntax, traditional: Old Options. (line 60)
* Options when reading archives: Reading. (line 6)
* Options, archive format specifying: Format Variations. (line 6)
* Options, format specifying: Format Variations. (line 6)
* ordinal numbers: General date syntax. (line 26)
* Overwriting old files, prevention: Writing. (line 6)
* Permissions of extracted files: Writing. (line 6)
* Pinard, F.: Authors of get_date. (line 14)
* pm in date strings: Time of day items. (line 21)
* Progress information: verbose. (line 6)
* Protecting old files: Writing. (line 6)
* pure numbers in date strings: Pure numbers in date strings.
(line 6)
* Reading file names from a file: files. (line 8)
* Reading incomplete records: Reading. (line 6)
* Record Size: Blocking Factor. (line 6)
* Records, incomplete: Reading. (line 6)
* Recursion in directories, avoiding: recurse. (line 6)
* relative items in date strings: Relative items in date strings.
(line 6)
* remote tape drive: Remote Tape Server. (line 6)
* Removing files from an archive: delete. (line 8)
* Replacing members with other members: append. (line 49)
* reporting bugs: Reports. (line 6)
* RESTORE_BEGIN: User Hooks. (line 38)
* RESTORE_END: User Hooks. (line 41)
* Resurrecting files from an archive: extract. (line 8)
* Retrieving files from an archive: extract. (line 8)
* return status: Synopsis. (line 67)
* rmt: Remote Tape Server. (line 6)
* RSH: General-Purpose Variables.
(line 67)
* RSH_COMMAND: General-Purpose Variables.
(line 72)
* Running out of space: Reading. (line 6)
* Running out of space during extraction: Scarce. (line 6)
* Salz, Rich: Authors of get_date. (line 6)
* simple backup method: backup. (line 64)
* SIMPLE_BACKUP_SUFFIX: backup. (line 68)
* SLEEP_MESSAGE: General-Purpose Variables.
(line 102)
* SLEEP_TIME: General-Purpose Variables.
(line 90)
* Small memory: Reading. (line 6)
* Space on the disk, recovering from lack of: Scarce. (line 6)
* Sparse Files: sparse. (line 6)
* Specifying archive members: Selecting Archive Members.
(line 6)
* Specifying files to act on: Selecting Archive Members.
(line 6)
* Standard input and output: file. (line 51)
* Standard output, writing extracted files to: Writing. (line 6)
* Status information: verbose. (line 6)
* Storing archives in compressed format: gzip. (line 6)
* Symbolic link as file name: dereference. (line 6)
* tape blocking: Blocking Factor. (line 194)
* tape marks: Many. (line 44)
* tape positioning: Many. (line 26)
* TAPE_FILE: General-Purpose Variables.
(line 19)
* Tapes, using --delete and: delete. (line 20)
* TAR: General-Purpose Variables.
(line 106)
* tar: What tar Does. (line 6)
* tar archive: Definitions. (line 6)
* tar entry: Naming tar Archives. (line 11)
* tar file: Naming tar Archives. (line 11)
* tar to standard input and output: file. (line 51)
* this in date strings: Relative items in date strings.
(line 33)
* time of day item: Time of day items. (line 6)
* time zone correction: Time of day items. (line 29)
* time zone item <1>: Time zone items. (line 6)
* time zone item: General date syntax. (line 41)
* today in date strings: Relative items in date strings.
(line 33)
* tomorrow in date strings: Relative items in date strings.
(line 29)
* Ultrix 3.1 and write failure: Remote Tape Server. (line 40)
* unpacking: Definitions. (line 22)
* Updating an archive: update. (line 8)
* uuencode: Applications. (line 8)
* Verbose operation: verbose. (line 6)
* Verifying a write operation: verify. (line 6)
* Verifying the currency of an archive: compare. (line 6)
* Version of the tar program: verbose. (line 6)
* version-control Emacs variable: backup. (line 49)
* VERSION_CONTROL: backup. (line 41)
* VOLNO_FILE: General-Purpose Variables.
(line 76)
* week in date strings: Relative items in date strings.
(line 15)
* Where is the archive?: file. (line 6)
* Working directory, specifying: directory. (line 6)
* Writing extracted files to standard output: Writing. (line 6)
* Writing new archives: file. (line 36)
* XLIST: General-Purpose Variables.
(line 80)
* year in date strings: Relative items in date strings.
(line 15)
* yesterday in date strings: Relative items in date strings.
(line 29)