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

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

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

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

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

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

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

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


File: tar.info,  Node: gzip,  Next: sparse,  Prev: Compression,  Up: Compression

Creating and Reading Compressed Archives
----------------------------------------

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

   You can have archives be compressed by using the `--gzip'
(`--gunzip', `--ungzip', `-z') option.  This will arrange for `tar' to
use the `gzip' program to be used to compress or uncompress the archive
wren writing or reading it.

   To use the older, obsolete, `compress' program, use the `--compress'
(`--uncompress', `-Z') option.  The GNU Project recommends you not use
`compress', because there is a patent covering the algorithm it uses.
You could be sued for patent infringment merely by running `compress'.

`-z'
`--gzip'
`--ungzip'
     Filter the archive through `gzip'.

   To perform compression and uncompression on the archive, `tar' runs
the `gzip' utility.  `tar' uses the default compression parameters; if
you need to override them, avoid the `--gzip' (`--gunzip', `--ungzip',
`-z') option and run the `gzip' utility explicitly.  (Or set the `GZIP'
environment variable.)  It is useful to be able to call the `gzip'
utility from within `tar' because the `gzip' utility by itself cannot
access remote tape drives.

   The `--gzip' (`--gunzip', `--ungzip', `-z') option will not work in
conjunction with the `--multi-volume' (`-M') option or the `--append'
(`-r'), `--update' (`-u'), `--concatenate' (`--catenate', `-A') and
`--delete' subcommands.  *Note Subcommands::, for more information on
these subcommands.

   You can use `--gzip' and `--gunzip' on physical devices (tape
drives, etc.) and remote files as well as on normal files; data to or
from such devices or remote files is reblocked by another copy of the
`tar' program to enforce the specified (or default) record size.

`-Z'
`--compress'
`--uncompress'
     Filter the archive through `compress'.  Otherwise like `--gzip'
     (`--gunzip', `--ungzip', `-z').

`--use-compress-program=PROG'
     Filter through PROG (must accept `-d').

   It is not exact to say that GNU `tar' is to work in concert with
`gzip' in a way similar to `zip', say.  Surely, it is possible that
`tar' and `gzip' be done with a single call, like in:

     $ tar cfz archive.tar.gz subdir

to save all of `subdir' into a `gzip''ed archive.  Later you can do:

     $ tar xfz archive.tar.gz

to explode and unpack.

   The difference is that the whole archive is compressed.  With `zip',
archive members are archived individually.  `tar''s method yields
better compression.  On the other hand, one can view the contents of a
`zip' archive without having to decompress it.  As for the `tar' and
`gzip' tandem, you need to decompress the archive to see its contents.
However, this may be done without needing disk space, by using pipes
internally:

     $ tar tfz archive.tar.gz

   (`tar' on MS-DOS and MS-Windows also supports this on-the-fly
compression with `gzip', but since pipes are simulated with disk files
on MS-DOS, you *do* need disk space to store the uncompressed copy,
while `tar' runs.  In particular, make sure the disk with the directory
which is the value of the environment variable `TMPDIR' has enough free
space, as many DOS users tend to point it to a RAM disk.)

   If there is no compress utility available, `tar' will report an
error.  *Please note* that the `compress' program may be covered by a
patent, and therefore we recommend you stop using it.

`--compress'
`--uncompress'
`-z'
`-Z'
     When this option is specified, `tar' will compress (when writing
     an archive), or uncompress (when reading an archive).  Used in
     conjunction with the `--create' (`-c'), `--extract' (`--get',
     `-x'), `--list' (`-t') and `--compare' (`--diff', `-d')
     subcommands.

     You can have archives be compressed by using the `--gzip'
     (`--gunzip', `--ungzip', `-z') option.  This will arrange for
     `tar' to use the `gzip' program to be used to compress or
     uncompress the archive wren writing or reading it.

     To use the older, obsolete, `compress' program, use the
     `--compress' (`--uncompress', `-Z') option.  The GNU Project
     recommends you not use `compress', because there is a patent
     covering the algorithm it uses.  You could be sued for patent
     infringment merely by running `compress'.

     About corrupted compressed archives: `gzip''ed files have no
     redundancy, for maximum compression.  The adaptive nature of the
     compression scheme means that the compression tables are implicitly
     spread all over the archive.  If you lose a few blocks, the dynamic
     construction of the compression tables becomes unsychronized, and
     there is little chance that you could recover later in the archive.

     There are pending suggestions for having a per-volume or per-file
     compression in GNU `tar'.  This would allow for viewing the
     contents without decompression, and for resynchronizing
     decompression at every volume or file, in case of corrupted
     archives.  Doing so, we might loose some compressibility.  But
     this would have make recovering easier.  So, there are pros and
     cons.  We'll see!

`--use-compress-program=PROG'
     Filter through PROG (must accept `-d').

   `--compress' (`--uncompress', `-Z') stores an archive in compressed
format.  This option is useful in saving time over networks and space
in pipes, and when storage space is at a premium.  `--compress'
(`--uncompress', `-Z') causes `tar' to compress when writing the
archive, or to uncompress when reading the archive.

   To perform compression and uncompression on the archive, `tar' runs
the `compress' utility.  `tar' uses the default compression parameters;
if you need to override them, avoid the `--compress' (`--uncompress',
`-Z') option and run the `compress' utility explicitly.  It is useful
to be able to call the `compress' utility from within `tar' because the
`compress' utility by itself cannot access remote tape drives.

   The `--compress' (`--uncompress', `-Z') option will not work in
conjunction with the `--multi-volume' (`-M') option or the `--append'
(`-r'), `--update' (`-u'), `--append' (`-r') and `--delete' subcommands.
, for more information on these subcommands.

   If there is no compress utility available, `tar' will report an
error.  *Please note* that the `compress' program may be covered by a
patent, and therefore we recommend you stop using it.

`--compress'
`--uncompress'
`-z'
`-Z'
     When this option is specified, `tar' will compress (when writing
     an archive), or uncompress (when reading an archive).  Used in
     conjunction with the `--create' (`-c'), `--extract' (`--get',
     `-x'), `--list' (`-t') and `--compare' (`--diff', `-d')
     subcommands.

   You can have archives be compressed by using the `--gzip'
(`--gunzip', `--ungzip', `-z') option.  This will arrange for `tar' to
use the `gzip' program to be used to compress or uncompress the archive
wren writing or reading it.

   To use the older, obsolete, `compress' program, use the `--compress'
(`--uncompress', `-Z') option.  The GNU Project recommends you not use
`compress', because there is a patent covering the algorithm it uses.
You could be sued for patent infringment merely by running `compress'.

   I have one question, or maybe it's a suggestion if there isn't a way
to do it now. I would like to use `--gzip' (`--gunzip', `--ungzip',
`-z'), but I'd also like the output to be fed through a program like
GNU `ecc' (actually, right now that's `exactly' what I'd like to use
:-)), basically adding ECC protection on top of compression.  It seems
as if this should be quite easy to do, but I can't work out exactly how
to go about it.  Of course, I can pipe the standard output of `tar'
through `ecc', but then I lose (though I haven't started using it yet,
I confess) the ability to have `tar' use `rmt' for it's I/O (I think).

   I think the most straightforward thing would be to let me specify a
general set of filters outboard of compression (preferably ordered, so
the order can be automatically reversed on input subcommands, and with
the options they require specifiable), but beggars shouldn't be
choosers and anything you decide on would be fine with me.

   By the way, I like `ecc' but if (as the comments say) it can't deal
with loss of block sync, I'm tempted to throw some time at adding that
capability.  Supposing I were to actually do such a thing and get it
(apparantly) working, do you accept contributed changes to utilities
like that?  (Leigh Clayton `loc@soliton.com', May 1995).

   Isn't that exactly the role of the `--use-compress-prog=PROGRAM'
option?  I never tried it myself, but I suspect you may want to write a
PROG script or program able to filter stdin to stdout to way you want.
It should recognize the `-d' option, for when extraction is needed
rather than creation.

   It has been reported that if one writes compressed data (through the
`--gzip' (`--gunzip', `--ungzip', `-z') or `--compress'
(`--uncompress', `-Z') options) to a DLT and tries to use the DLT
compression mode, the data will actually get bigger and one will end up
with less space on the tape.


File: tar.info,  Node: sparse,  Prev: gzip,  Up: Compression

Archiving Sparse Files
----------------------

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

`-S'
`--sparse'
     Handle sparse files efficiently.

   This option causes all files to be put in the archive to be tested
for sparseness, and handled specially if they are.  The `--sparse'
(`-S') option is useful when many `dbm' files, for example, are being
backed up.  Using this option dramatically decreases the amount of
space needed to store such a file.

   However, users should be well aware that at archive creation time,
GNU `tar' still has to read whole disk file to locate the "holes", and
so, even if sparse files use little space on disk and in the archive,
they may sometimes require inordinate amount of time for analysis.
This reading is required in all cases and is not related to the fact
the `--sparse' (`-S') option is used or not, so by merely *not* using
the option, you are not saving time(1).

   In later versions, this option may be removed, and the testing and
treatment of sparse files may be done automatically with any special
GNU options.  For now, it is an option needing to be specified on the
command line with the creation or updating of an archive.

   Files in the filesystem occasionally have "holes."  A hole in a file
is a section of the file's contents which was never written.  The
contents of a hole read as all zeroes.  On many operating systems,
actual disk storage is not allocated for holes, but they are counted in
the length of the file.  If you archive such a file, `tar' could create
an archive longer than the original.  To have `tar' attempt to
recognize the holes in a file, use `--sparse' (`-S').  When you use the
`--sparse' (`-S') option, then, for any file using less disk space than
would be expected from its length, `tar' searches the file for
consecutive stretches of zeroes.  It then records in the archive for
the file where the consecutive stretches of zeroes are, and only
archives the "real contents" of the file.  On extraction (using
`--sparse' (`-S') is not needed on extraction) any such files have
holes created wherever the continuous stretches of zeroes were found.
Thus, if you use `--sparse' (`-S'), `tar' archives won't take more
space than the original.

   A file is sparse if it contains blocks of zeroes whose existence is
recorded, but that have no space allocated on disk.  When you specify
the `--sparse' (`-S') option in conjunction with the `--create' (`-c')
subcommand, `tar' tests all files for sparseness while archiving.  If
`tar' finds a file to be sparse, it uses a sparse representation of the
file in the archive.  *Note create::, for more information about
creating archives.

   `--sparse' (`-S') is useful when archiving files, such as dbm files,
that are likely to contain many nulls.  This option dramatically
decreases the amount of space needed to store such an archive.

     *Please Note:* Always use `--sparse' (`-S') when performing file
     system backups, to avoid archiving the expanded forms of files
     stored sparsely in the system.

     Even if your system has no sparse files currently, some may be
     created in the future.  If you use `--sparse' (`-S') while making
     file system backups as a matter of course, you can be assured the
     archive will never take more space on the media than the files
     take on disk (otherwise, archiving a disk filled with sparse files
     might take hundreds of tapes).

   `tar' ignores the `--sparse' (`-S') option when reading an archive.

`--sparse'
`-S'
     Files stored sparsely in the file system are represented sparsely
     in the archive.  Use in conjunction with write subcommands.

   However, users should be well aware that at archive creation time,
GNU `tar' still has to read the whole disk file to locate the "holes",
and so, even if sparse files use little space on disk and in the
archive, they may sometimes require inordinate amount of time for
reading and examining all-zero blocks of a file.  Although it works,
it's painfully slow for a large (sparse) file, even though the
resulting tar archive may be small.  (One user reports that dumping a
`core' file of over 400 megabytes, but with only about 3 megabytes of
actual data, took about 9 minutes on a Sun Sparstation ELC, with full
CPU utilisation.)

   This reading is required in all cases and is not related to the fact
the `--sparse' (`-S') option is used or not, so by merely *not* using
the option, you are not saving time(2).

   Programs like `dump' do not have to read the entire file; by
examining the file system directly, they can determine in advance
exactly where the holes are and thus avoid reading through them.  The
only data it need read are the actual allocated data blocks.  GNU `tar'
uses a more portable and straightforward archiving approach, it would
be fairly difficult that it does otherwise.  Elizabeth Zwicky writes to
`comp.unix.internals', on 1990-12-10:

     What I did say is that you cannot tell the difference between a
     hole and an equivalent number of nulls without reading raw blocks.
     `st_blocks' at best tells you how many holes there are; it
     doesn't tell you *where*.  Just as programs may, conceivably, care
     what `st_blocks' is (care to name one that does?), they may also
     care where the holes are (I have no examples of this one either,
     but it's equally imaginable).

     I conclude from this that good archivers are not portable.  One can
     arguably conclude that if you want a portable program, you can in
     good conscience restore files with as many holes as possible,
     since you can't get it right.

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

   (1)  Well!  We should say the whole truth, here.  When `--sparse'
(`-S') is selected while creating an archive, the current `tar'
algorithm requires sparse files to be read twice, not once.  We hope to
develop a new archive format for saving sparse files in which one pass
will be sufficient.

   (2)  Well!  We should say the whole truth, here.  When `--sparse'
(`-S') is selected while creating an archive, the current `tar'
algorithm requires sparse files to be read twice, not once.  We hope to
develop a new archive format for saving sparse files in which one pass
will be sufficient.


File: tar.info,  Node: Attributes,  Next: Standard,  Prev: Compression,  Up: Formats

Handling File Attributes
========================

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

   When `tar' reads files, this causes them to have the access times
updated.  To have `tar' attempt to set the access times back to what
they were before they were read, use the `--atime-preserve' option.
This doesn't work for files that you don't own, unless you're root, and
it doesn't interact with incremental dumps nicely (*note Backups::.),
but it is good enough for some purposes.

   Handling of file attributes

`--atime-preserve'
     Do not change access times on dumped files.  This option doesn't
     have any effect on MS-DOS, since `atime' is not supported by the
     DOS FAT file system.  (It *does* work on MS-Windows 9X.)

`-m'
`--touch'
     Do not extract file modified time.

     When this option is used, `tar' leaves the modification times of
     the files it extracts as the time when the files were extracted,
     instead of setting it to the time recorded in the archive.

     This option is meaningless with `--list' (`-t').

`--same-owner'
     Create extracted files with the same ownership they have in the
     archive.

     When using super-user at extraction time, ownership is always
     restored.  So, this option is meaningful only for non-root users,
     when `tar' is executed on those systems able to give files away.
     This is considered as a security flaw by many people, at least
     because it makes quite difficult to correctly account users for
     the disk space they occupy.  Also, the `suid' or `sgid' attributes
     of files are easily and silently lost when files are given away.

     When writing an archive, `tar' writes the user id and user name
     separately.  If it can't find a user name (because the user id is
     not in `/etc/passwd'), then it does not write one.  When restoring,
     and doing a `chmod' like when you use `--same-permissions'
     (`--preserve-permissions', `-p'), () it tries to look the name (if
     one was written) up in `/etc/passwd'.  If it fails, then it uses
     the user id stored in the archive instead.

`--numeric-owner'
     The `--numeric-owner' option allows (ANSI) archives to be written
     without user/group name information or such information to be
     ignored when extracting.  It effectively disables the generation
     and/or use of user/group name information.  This option forces
     extraction using the numeric ids from the archive, ignoring the
     names.

     This is useful in certain circumstances, when restoring a backup
     from an emergency floppy with different passwd/group files for
     example.  It is otherwise impossible to extract files with the
     right ownerships if the password file in use during the extraction
     does not match the one belonging to the filesystem(s) being
     extracted.  This occurs, for example, if you are restoring your
     files after a major crash and had booted from an emergency floppy
     with no password file or put your disk into another machine to do
     the restore.

     The numeric ids are *always* saved into `tar' archives.  The
     identifying names are added at create time when provided by the
     system, unless `--old-archive' (`-o') is used.  Numeric ids could
     be used when moving archives between a collection of machines using
     a centralized management for attribution of numeric ids to users
     and groups.  This is often made through using the NIS capabilities.

     When making a `tar' file for distribution to other sites, it is
     sometimes cleaner to use a single owner for all files in the
     distribution, and nicer to specify the write permission bits of the
     files as stored in the archive independently of their actual value
     on the file system.  The way to prepare a clean distribution is
     usually to have some Makefile rule creating a directory, copying
     all needed files in that directory, then setting ownership and
     permissions as wanted (there are a lot of possible schemes), and
     only then making a `tar' archive out of this directory, before
     cleaning everything out.  Of course, we could add a lot of options
     to GNU `tar' for fine tuning permissions and ownership.  This is
     not the good way, I think.  GNU `tar' is already crowded with
     options and moreover, the approach just explained gives you a
     great deal of control already.

`--group=GROUP'
     Files added to the `tar' archive will have a group id of GROUP,
     rather than the group from the source file.  GROUP is first decoded
     as a group symbolic name, but if this interpretation fails, it has
     to be a decimal numeric group ID.  `tar' on MS-DOS/MS-Windows
     allows GROUP to be *any* string.  These systems don't support group
     id's, so `tar' allows them to give away files to anybody.  If
     GROUP consists only of digits, it is treated as a numeric GID;
     otherwise it is treated as a group name.

`--owner=USER'
     Specifies that `tar' should use USER as the owner of members when
     creating archives, instead of the user associated with the source
     file.  USER is first decoded as a user symbolic name, but if this
     interpretation fails, it has to be a decimal numeric user ID.

     There is no value indicating a missing number, and `0' usually
     means `root'.  Some people like to force `0' as the value to offer
     in their distributions for the owner of files, because the `root'
     user is anonymous anyway, so that might as well be the owner of
     anonymous archives.

     `tar' on MS-DOS/MS-Windows allows USER to be *any* string.  These
     systems don't support file ownership, so `tar' allows them to give
     away files to anybody.  If USER includes only digits, it is
     treated as a numeric UID; otherwise, it is treated as a user name.

`-p'
`--same-permissions'
`--preserve-permissions'
     Extract all protection information.

     This option causes `tar' to set the modes (access permissions) of
     extracted files exactly as recorded in the archive.  If this option
     is not used, the current `umask' setting limits the permissions on
     extracted files.

     This option is meaningless with `--list' (`-t').

`--preserve'
     Same as both `--same-permissions' (`--preserve-permissions', `-p')
     and `--same-order' (`--preserve-order', `-s').

     The `--preserve' option has no equivalent short option name.  It
     is equivalent to `--same-permissions' (`--preserve-permissions',
     `-p') plus `--same-order' (`--preserve-order', `-s').


File: tar.info,  Node: Standard,  Next: Extensions,  Prev: Attributes,  Up: Formats

The Standard Format
===================

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

   While an archive may contain many files, the archive itself is a
single ordinary file.  Like any other file, an archive file can be
written to a storage device such as a tape or disk, sent through a pipe
or over a network, saved on the active file system, or even stored in
another archive.  An archive file is not easy to read or manipulate
without using the `tar' utility or Tar mode in GNU Emacs.

   Physically, an archive consists of a series of file entries
terminated by an end-of-archive entry, which consists of 512 zero
bytes.  A file entry usually describes one of the files in the archive
(an "archive member"), and consists of a file header and the contents
of the file.  File headers contain file names and statistics, checksum
information which `tar' uses to detect file corruption, and information
about file types.

   Archives are permitted to have more than one member with the same
member name.  One way this situation can occur is if more than one
version of a file has been stored in the archive.  For information
about adding new versions of a file to an archive, see *Note update::,
and to learn more about having more than one archive member with the
same name, see .

   In addition to entries describing archive members, an archive may
contain entries which `tar' itself uses to store information.
*Note label::, for an example of such an archive entry.

   A `tar' archive file contains a series of blocks.  Each block
contains `BLOCKSIZE' bytes.  Although this format may be thought of as
being on magnetic tape, other media are often used.

   Each file archived is represented by a header block which describes
the file, followed by zero or more blocks which give the contents of
the file.  At the end of the archive file there may be a block filled
with binary zeros as an end-of-file marker.  A reasonable system should
write a block of zeros at the end, but must not assume that such a
block exists when reading an archive.

   The blocks may be "blocked" for physical I/O subcommands.  Each
record of N blocks (where N is set by the `--blocking-factor=BLOCKS'
(`-b BLOCKS') option to `tar') is written with a single `write ()'
subcommand.  On magnetic tapes, the result of such a write is a single
record.  When writing an archive, the last record of blocks should be
written at the full size, with blocks after the zero block containing
all zeros.  When reading an archive, a reasonable system should
properly handle an archive whose last record is shorter than the rest,
or which contains garbage records after a zero block.

   The header block is defined in C as follows.  In the GNU `tar'
distribution, this is part of file `src/tar.h':

     /* GNU tar Archive Format description.  */
     
     /* If OLDGNU_COMPATIBILITY is set, tar produces archives which, by default,
        are readable by older versions of GNU tar.  This can be overriden by
        using --posix; in this case, POSIXLY_CORRECT in environment may be set
        for enforcing stricter conformance.  If OLDGNU_COMPATIBILITY is zero or
        undefined, tar will eventually produces archives which, by default, POSIX
        compatible; then either using --posix or defining POSIXLY_CORRECT
        enforces stricter conformance.
     
        This #define will disappear in a few years.  FP, June 1995.  */
     #define OLDGNU_COMPATIBILITY 1
     
     /*---------------------------------------------.
     | `tar' Header Block, from POSIX 1003.1-1990.  |
     `---------------------------------------------*/
     
     /* POSIX header.  */
     
     struct posix_header
     {                               /* byte offset */
       char name[100];               /*   0 */
       char mode[8];                 /* 100 */
       char uid[8];                  /* 108 */
       char gid[8];                  /* 116 */
       char size[12];                /* 124 */
       char mtime[12];               /* 136 */
       char chksum[8];               /* 148 */
       char typeflag;                /* 156 */
       char linkname[100];           /* 157 */
       char magic[6];                /* 257 */
       char version[2];              /* 263 */
       char uname[32];               /* 265 */
       char gname[32];               /* 297 */
       char devmajor[8];             /* 329 */
       char devminor[8];             /* 337 */
       char prefix[155];             /* 345 */
                                     /* 500 */
     };
     
     #define TMAGIC   "ustar"        /* ustar and a null */
     #define TMAGLEN  6
     #define TVERSION "00"           /* 00 and no null */
     #define TVERSLEN 2
     
     /* Values used in typeflag field.  */
     #define REGTYPE  '0'            /* regular file */
     #define AREGTYPE '\0'           /* regular file */
     #define LNKTYPE  '1'            /* link */
     #define SYMTYPE  '2'            /* reserved */
     #define CHRTYPE  '3'            /* character special */
     #define BLKTYPE  '4'            /* block special */
     #define DIRTYPE  '5'            /* directory */
     #define FIFOTYPE '6'            /* FIFO special */
     #define CONTTYPE '7'            /* reserved */
     
     /* Bits used in the mode field, values in octal.  */
     #define TSUID    04000          /* set UID on execution */
     #define TSGID    02000          /* set GID on execution */
     #define TSVTX    01000          /* reserved */
                                     /* file permissions */
     #define TUREAD   00400          /* read by owner */
     #define TUWRITE  00200          /* write by owner */
     #define TUEXEC   00100          /* execute/search by owner */
     #define TGREAD   00040          /* read by group */
     #define TGWRITE  00020          /* write by group */
     #define TGEXEC   00010          /* execute/search by group */
     #define TOREAD   00004          /* read by other */
     #define TOWRITE  00002          /* write by other */
     #define TOEXEC   00001          /* execute/search by other */
     
     /*-------------------------------------.
     | `tar' Header Block, GNU extensions.  |
     `-------------------------------------*/
     
     /* In GNU tar, SYMTYPE is for to symbolic links, and CONTTYPE is for
        contiguous files, so maybe disobeying the `reserved' comment in POSIX
        header description.  I suspect these were meant to be used this way, and
        should not have really been `reserved' in the published standards.  */
     
     /* *BEWARE* *BEWARE* *BEWARE* that the following information is still
        boiling, and may change.  Even if the OLDGNU format description should be
        accurate, the so-called GNU format is not yet fully decided.  It is
        surely meant to use only extensions allowed by POSIX, but the sketch
        below repeats some ugliness from the OLDGNU format, which should rather
        go away.  Sparse files should be saved in such a way that they do *not*
        require two passes at archive creation time.  Huge files get some POSIX
        fields to overflow, alternate solutions have to be sought for this.  */
     
     /* Descriptor for a single file hole.  */
     
     struct sparse
     {                               /* byte offset */
       char offset[12];              /*   0 */
       char numbytes[12];            /*  12 */
                                     /*  24 */
     };
     
     /* Sparse files are not supported in POSIX ustar format.  For sparse files
        with a POSIX header, a GNU extra header is provided which holds overall
        sparse information and a few sparse descriptors.  When an old GNU header
        replaces both the POSIX header and the GNU extra header, it holds some
        sparse descriptors too.  Whether POSIX or not, if more sparse descriptors
        are still needed, they are put into as many successive sparse headers as
        necessary.  The following constants tell how many sparse descriptors fit
        in each kind of header able to hold them.  */
     
     #define SPARSES_IN_EXTRA_HEADER  16
     #define SPARSES_IN_OLDGNU_HEADER 4
     #define SPARSES_IN_SPARSE_HEADER 21
     
     /* The GNU extra header contains some information GNU tar needs, but not
        foreseen in POSIX header format.  It is only used after a POSIX header
        (and never with old GNU headers), and immediately follows this POSIX
        header, when typeflag is a letter rather than a digit, so signaling a GNU
        extension.  */
     
     struct extra_header
     {                               /* byte offset */
       char atime[12];               /*   0 */
       char ctime[12];               /*  12 */
       char offset[12];              /*  24 */
       char realsize[12];            /*  36 */
       char longnames[4];            /*  48 */
       char unused_pad1[68];         /*  52 */
       struct sparse sp[SPARSES_IN_EXTRA_HEADER];
                                     /* 120 */
       char isextended;              /* 504 */
                                     /* 505 */
     };
     
     /* Extension header for sparse files, used immediately after the GNU extra
        header, and used only if all sparse information cannot fit into that
        extra header.  There might even be many such extension headers, one after
        the other, until all sparse information has been recorded.  */
     
     struct sparse_header
     {                               /* byte offset */
       struct sparse sp[SPARSES_IN_SPARSE_HEADER];
                                     /*   0 */
       char isextended;              /* 504 */
                                     /* 505 */
     };
     
     /* The old GNU format header conflicts with POSIX format in such a way that
        POSIX archives may fool old GNU tar's, and POSIX tar's might well be
        fooled by old GNU tar archives.  An old GNU format header uses the space
        used by the prefix field in a POSIX header, and cumulates information
        normally found in a GNU extra header.  With an old GNU tar header, we
        never see any POSIX header nor GNU extra header.  Supplementary sparse
        headers are allowed, however.  */
     
     struct oldgnu_header
     {                               /* byte offset */
       char unused_pad1[345];        /*   0 */
       char atime[12];               /* 345 */
       char ctime[12];               /* 357 */
       char offset[12];              /* 369 */
       char longnames[4];            /* 381 */
       char unused_pad2;             /* 385 */
       struct sparse sp[SPARSES_IN_OLDGNU_HEADER];
                                     /* 386 */
       char isextended;              /* 482 */
       char realsize[12];            /* 483 */
                                     /* 495 */
     };
     
     /* OLDGNU_MAGIC uses both magic and version fields, which are contiguous.
        Found in an archive, it indicates an old GNU header format, which will be
        hopefully become obsolescent.  With OLDGNU_MAGIC, uname and gname are
        valid, though the header is not truly POSIX conforming.  */
     #define OLDGNU_MAGIC "ustar  "  /* 7 chars and a null */
     
     /* The standards committee allows only capital A through capital Z for
        user-defined expansion.  */
     
     /* This is a dir entry that contains the names of files that were in the
        dir at the time the dump was made.  */
     #define GNUTYPE_DUMPDIR 'D'
     
     /* Identifies the *next* file on the tape as having a long linkname.  */
     #define GNUTYPE_LONGLINK 'K'
     
     /* Identifies the *next* file on the tape as having a long name.  */
     #define GNUTYPE_LONGNAME 'L'
     
     /* This is the continuation of a file that began on another volume.  */
     #define GNUTYPE_MULTIVOL 'M'
     
     /* For storing filenames that do not fit into the main header.  */
     #define GNUTYPE_NAMES 'N'
     
     /* This is for sparse files.  */
     #define GNUTYPE_SPARSE 'S'
     
     /* This file is a tape/volume header.  Ignore it on extraction.  */
     #define GNUTYPE_VOLHDR 'V'
     
     /*--------------------------------------.
     | tar Header Block, overall structure.  |
     `--------------------------------------*/
     
     /* tar files are made in basic blocks of this size.  */
     #define BLOCKSIZE ((size_t) 512)
     
     enum archive_format
     {
       DEFAULT_FORMAT,               /* format to be decided later */
       V7_FORMAT,                    /* old V7 tar format */
       OLDGNU_FORMAT,                /* GNU format as per before tar 2.0 */
       POSIX_FORMAT,                 /* restricted, pure POSIX format */
       GNU_FORMAT                    /* POSIX format with GNU extensions */
     };
     
     union block
     {
       char buffer[BLOCKSIZE];
       struct posix_header header;
       struct extra_header extra_header;
       struct oldgnu_header oldgnu_header;
       struct sparse_header sparse_header;
     };
     
     /* End of Format description.  */

   All characters in header blocks are represented by using 8-bit
characters in the local variant of ASCII.  Each field within the
structure is contiguous; that is, there is no padding used within the
structure.  Each character on the archive medium is stored contiguously.

   Bytes representing the contents of files (after the header block of
each file) are not translated in any way and are not constrained to
represent characters in any character set.  The `tar' format does not
distinguish text files from binary files, and no translation of file
contents is performed.

   The `name', `linkname', `magic', `uname', and `gname' are
null-terminated character strings.  All other fileds are zero-filled
octal numbers in ASCII.  Each numeric field of width W contains W minus
2 digits, a space, and a null, except `size', and `mtime', which do not
contain the trailing null.

   The `name' field is the file name of the file, with directory names
(if any) preceding the file name, separated by slashes.

   The `mode' field provides nine bits specifying file permissions and
three bits to specify the Set UID, Set GID, and Save Text ("sticky")
modes.  Values for these bits are defined above.  When special
permissions are required to create a file with a given mode, and the
user restoring files from the archive does not hold such permissions,
the mode bit(s) specifying those special permissions are ignored.
Modes which are not supported by the operating system restoring files
from the archive will be ignored.  Unsupported modes should be faked up
when creating or updating an archive; e.g. the group permission could
be copied from the *other* permission.

   The `uid' and `gid' fields are the numeric user and group ID of the
file owners, respectively.  If the operating system does not support
numeric user or group IDs, these fields should be ignored.

   The `size' field is the size of the file in bytes; linked files are
archived with this field specified as zero.  *Note Backups::, in
particular the `--incremental' (`-G') option.

   The `mtime' field is the modification time of the file at the time
it was archived.  It is the ASCII representation of the octal value of
the last time the file was modified, represented as an integer number of
seconds since January 1, 1970, 00:00 Coordinated Universal Time.

   The `chksum' field is the ASCII representation of the octal value of
the simple sum of all bytes in the header block.  Each 8-bit byte in
the header is added to an unsigned integer, initialized to zero, the
precision of which shall be no less than seventeen bits.  When
calculating the checksum, the `chksum' field is treated as if it were
all blanks.

   The `typeflag' field specifies the type of file archived.  If a
particular implementation does not recognize or permit the specified
type, the file will be extracted as if it were a regular file.  As this
action occurs, `tar' issues a warning to the standard error.

   The `atime' and `ctime' fields are used in making incremental
backups; they store, respectively, the particular file's access time
and last inode-change time.

   The `offset' is used by the `--multi-volume' (`-M') option, when
making a multi-volume archive.  The offset is number of bytes into the
file that we need to restart at to continue the file on the next tape,
i.e., where we store the location that a continued file is continued at.

   The following fields were added to deal with sparse files.  A file
is "sparse" if it takes in unallocated blocks which end up being
represented as zeros, i.e., no useful data.  A test to see if a file is
sparse is to look at the number blocks allocated for it versus the
number of characters in the file; if there are fewer blocks allocated
for the file than would normally be allocated for a file of that size,
then the file is sparse.  This is the method `tar' uses to detect a
sparse file, and once such a file is detected, it is treated
differently from non-sparse files.

   Sparse files are often `dbm' files, or other database-type files
which have data at some points and emptiness in the greater part of the
file.  Such files can appear to be very large when an `ls -l' is done
on them, when in truth, there may be a very small amount of important
data contained in the file.  It is thus undesirable to have `tar' think
that it must back up this entire file, as great quantities of room are
wasted on empty blocks, which can lead to running out of room on a tape
far earlier than is necessary.  Thus, sparse files are dealt with so
that these empty blocks are not written to the tape.  Instead, what is
written to the tape is a description, of sorts, of the sparse file:
where the holes are, how big the holes are, and how much data is found
at the end of the hole.  This way, the file takes up potentially far
less room on the tape, and when the file is extracted later on, it will
look exactly the way it looked beforehand.  The following is a
description of the fields used to handle a sparse file:

   The `sp' is an array of `struct sparse'.  Each `struct sparse'
contains two 12-character strings which represent an offset into the
file and a number of bytes to be written at that offset.  The offset is
absolute, and not relative to the offset in preceding array element.

   The header can hold four of these `struct sparse' at the moment; if
more are needed, they are not stored in the header.

   The `isextended' flag is set when an `extended_header' is needed to
deal with a file.  Note that this means that this flag can only be set
when dealing with a sparse file, and it is only set in the event that
the description of the file will not fit in the alloted room for sparse
structures in the header.  In other words, an extended_header is needed.

   The `extended_header' structure is used for sparse files which need
more sparse structures than can fit in the header.  The header can fit
4 such structures; if more are needed, the flag `isextended' gets set
and the next block is an `extended_header'.

   Each `extended_header' structure contains an array of 21 sparse
structures, along with a similar `isextended' flag that the header had.
There can be an indeterminate number of such `extended_header's to
describe a sparse file.

`REGTYPE'
`AREGTYPE'
     These flags represent a regular file.  In order to be compatible
     with older versions of `tar', a `typeflag' value of `AREGTYPE'
     should be silently recognized as a regular file.  New archives
     should be created using `REGTYPE'.  Also, for backward
     compatibility, `tar' treats a regular file whose name ends with a
     slash as a directory.

`LNKTYPE'
     This flag represents a file linked to another file, of any type,
     previously archived.  Such files are identified in Unix by each
     file having the same device and inode number.  The linked-to name
     is specified in the `linkname' field with a trailing null.

`SYMTYPE'
     This represents a symbolic link to another file.  The linked-to
     name is specified in the `linkname' field with a trailing null.

`CHRTYPE'
`BLKTYPE'
     These represent character special files and block special files
     respectively.  In this case the `devmajor' and `devminor' fields
     will contain the major and minor device numbers respectively.
     Operating systems may map the device specifications to their own
     local specification, or may ignore the entry.

`DIRTYPE'
     This flag specifies a directory or sub-directory.  The directory
     name in the `name' field should end with a slash.  On systems where
     disk allocation is performed on a directory basis, the `size' field
     will contain the maximum number of bytes (which may be rounded to
     the nearest disk block allocation unit) which the directory may
     hold.  A `size' field of zero indicates no such limiting.  Systems
     which do not support limiting in this manner should ignore the
     `size' field.

`FIFOTYPE'
     This specifies a FIFO special file.  Note that the archiving of a
     FIFO file archives the existence of this file and not its contents.

`CONTTYPE'
     This specifies a contiguous file, which is the same as a normal
     file except that, in operating systems which support it, all its
     space is allocated contiguously on the disk.  Operating systems
     which do not allow contiguous allocation should silently treat this
     type as a normal file.

`A' ... `Z'
     These are reserved for custom implementations.  Some of these are
     used in the GNU modified format, as described below.

   Other values are reserved for specification in future revisions of
the P1003 standard, and should not be used by any `tar' program.

   The `magic' field indicates that this archive was output in the
P1003 archive format.  If this field contains `TMAGIC', the `uname' and
`gname' fields will contain the ASCII representation of the owner and
group of the file respectively.  If found, the user and group IDs are
used rather than the values in the `uid' and `gid' fields.

   For references, see ISO/IEC 9945-1:1990 or IEEE Std 1003.1-1990,
pages 169-173 (section 10.1) for `Archive/Interchange File Format'; and
IEEE Std 1003.2-1992, pages 380-388 (section 4.48) and pages 936-940
(section E.4.48) for `pax - Portable archive interchange'.


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

GNU Extensions to the Archive Format
====================================

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

   The GNU format uses additional file types to describe new types of
files in an archive.  These are listed below.

`GNUTYPE_DUMPDIR'
`'D''
     This represents a directory and a list of files created by the
     `--incremental' (`-G') option.  The `size' field gives the total
     size of the associated list of files.  Each file name is preceded
     by either a `Y' (the file should be in this archive) or an `N'.
     (The file is a directory, or is not stored in the archive.)  Each
     file name is terminated by a null.  There is an additional null
     after the last file name.

`GNUTYPE_MULTIVOL'
`'M''
     This represents a file continued from another volume of a
     multi-volume archive created with the `--multi-volume' (`-M')
     option.  The original type of the file is not given here.  The
     `size' field gives the maximum size of this piece of the file
     (assuming the volume does not end before the file is written out).
     The `offset' field gives the offset from the beginning of the
     file where this part of the file begins.  Thus `size' plus
     `offset' should equal the original size of the file.

`GNUTYPE_SPARSE'
`'S''
     This flag indicates that we are dealing with a sparse file.  Note
     that archiving a sparse file requires special subcommands to find
     holes in the file, which mark the positions of these holes, along
     with the number of bytes of data to be found after the hole.

`GNUTYPE_VOLHDR'
`'V''
     This file type is used to mark the volume header that was given
     with the `--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') option when
     the archive was created.  The `name' field contains the `name'
     given after the `--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL')
     option.  The `size' field is zero.  Only the first file in each
     volume of an archive should have this type.

   You may have trouble reading a GNU format archive on a non-GNU
system if the options `--incremental' (`-G'), `--multi-volume' (`-M'),
`--sparse' (`-S'), or `--label=ARCHIVE-LABEL' (`-V ARCHIVE-LABEL') were
used when writing the archive.  In general, if `tar' does not use the
GNU-added fields of the header, other versions of `tar' should be able
to read the archive.  Otherwise, the `tar' program will give an error,
the most likely one being a checksum error.

