-In most cases, a @emph{new} format archive can be read by an @emph{old}
-@code{tar} program without serious trouble, so this option should
-seldom be needed. On the other hand, most modern @code{tar}s are
-able to read old format archives, so it might be safer for you to
-always use @value{op-old-archive} for your distributions.
-
-@node posix, Checksumming, old, Portability
-@subsection GNU @code{tar} and POSIX @code{tar}
-
-GNU @code{tar} was based on an early draft of the POSIX 1003.1
-@code{ustar} standard. GNU extensions to @code{tar}, such as the
-support for file names longer than 100 characters, use portions of the
-@code{tar} header record which were specified in that POSIX draft as
-unused. Subsequent changes in POSIX have allocated the same parts of
-the header record for other purposes. As a result, GNU @code{tar} is
-incompatible with the current POSIX spec, and with @code{tar} programs
-that follow it.
-
-We plan to reimplement these GNU extensions in a new way which is
-upward compatible with the latest POSIX @code{tar} format, but we
-don't know when this will be done.
-
-In the mean time, there is simply no telling what might happen if you
-read a GNU @code{tar} archive, which uses the GNU extensions, using
-some other @code{tar} program. So if you want to read the archive
-with another @code{tar} program, be sure to write it using the
-@samp{--old-archive} option (@samp{-o}).
-
-@FIXME{is there a way to tell which flavor of tar was used to write a
-particular archive before you try to read it?}
-
-Traditionally, old @code{tar}s have a limit of 100 characters. GNU
-@code{tar} attempted two different approaches to overcome this limit,
-using and extending a format specified by a draft of some P1003.1.
-The first way was not that successful, and involved @file{@@MaNgLeD@@}
-file names, or such; while a second approach used @file{././@@LongLink}
-and other tricks, yielding better success. In theory, GNU @code{tar}
-should be able to handle file names of practically unlimited length.
-So, if GNU @code{tar} fails to dump and retrieve files having more
-than 100 characters, then there is a bug in GNU @code{tar}, indeed.
-
-But, being strictly POSIX, the limit was still 100 characters.
-For various other purposes, GNU @code{tar} used areas left unassigned
-in the POSIX draft. POSIX later revised P1003.1 @code{ustar} format by
-assigning previously unused header fields, in such a way that the upper
-limit for file name length was raised to 256 characters. However, the
-actual POSIX limit oscillates between 100 and 256, depending on the
-precise location of slashes in full file name (this is rather ugly).
-Since GNU @code{tar} use the same fields for quite other purposes,
-it became incompatible with the latest POSIX standards.
-
-For longer or non-fitting file names, we plan to use yet another set
-of GNU extensions, but this time, complying with the provisions POSIX
-offers for extending the format, rather than conflicting with it.
-Whenever an archive uses old GNU @code{tar} extension format or POSIX
-extensions, would it be for very long file names or other specialities,
-this archive becomes non-portable to other @code{tar} implementations.
-In fact, anything can happen. The most forgiving @code{tar}s will
-merely unpack the file using a wrong name, and maybe create another
-file named something like @file{@@LongName}, with the true file name
-in it. @code{tar}s not protecting themselves may segment violate!
-
-Compatibility concerns make all this thing more difficult, as we
-will have to support @emph{all} these things together, for a while.
-GNU @code{tar} should be able to produce and read true POSIX format
-files, while being able to detect old GNU @code{tar} formats, besides
-old V7 format, and process them conveniently. It would take years
-before this whole area stabilizes@dots{}
-
-There are plans to raise this 100 limit to 256, and yet produce POSIX
-conforming archives. Past 256, I do not know yet if GNU @code{tar}
-will go non-POSIX again, or merely refuse to archive the file.
-
-There are plans so GNU @code{tar} support more fully the latest POSIX
-format, while being able to read old V7 format, GNU (semi-POSIX plus
-extension), as well as full POSIX. One may ask if there is part of
-the POSIX format that we still cannot support. This simple question
-has a complex answer. Maybe that, on intimate look, some strong
-limitations will pop up, but until now, nothing sounds too difficult
-(but see below). I only have these few pages of POSIX telling about
-`Extended tar Format' (P1003.1-1990 -- section 10.1.1), and there are
-references to other parts of the standard I do not have, which should
-normally enforce limitations on stored file names (I suspect things
-like fixing what @kbd{/} and @kbd{@key{NUL}} means). There are also
-some points which the standard does not make clear, Existing practice
-will then drive what I should do.
-
-POSIX mandates that, when a file name cannot fit within 100 to
-256 characters (the variance comes from the fact a @kbd{/} is
-ideally needed as the 156'th character), or a link name cannot
-fit within 100 characters, a warning should be issued and the file
-@emph{not} be stored. Unless some @value{op-posix} option is given
-(or @code{POSIXLY_CORRECT} is set), I suspect that GNU @code{tar}
-should disobey this specification, and automatically switch to using
-GNU extensions to overcome file name or link name length limitations.
-
-There is a problem, however, which I did not intimately studied yet.
-Given a truly POSIX archive with names having more than 100 characters,
-I guess that GNU @code{tar} up to 1.11.8 will process it as if it were an
-old V7 archive, and be fooled by some fields which are coded differently.
-So, the question is to decide if the next generation of GNU @code{tar}
-should produce POSIX format by default, whenever possible, producing
-archives older versions of GNU @code{tar} might not be able to read
-correctly. I fear that we will have to suffer such a choice one of these
-days, if we want GNU @code{tar} to go closer to POSIX. We can rush it.
-Another possibility is to produce the current GNU @code{tar} format
-by default for a few years, but have GNU @code{tar} versions from some
-1.@var{POSIX} and up able to recognize all three formats, and let older
-GNU @code{tar} fade out slowly. Then, we could switch to producing POSIX
-format by default, with not much harm to those still having (very old at
-that time) GNU @code{tar} versions prior to 1.@var{POSIX}.
-
-POSIX format cannot represent very long names, volume headers,
-splitting of files in multi-volumes, sparse files, and incremental
-dumps; these would be all disallowed if @value{op-posix} or
-@code{POSIXLY_CORRECT}. Otherwise, if @code{tar} is given long
-names, or @samp{-[VMSgG]}, then it should automatically go non-POSIX.
-I think this is easily granted without much discussion.
-
-Another point is that only @code{mtime} is stored in POSIX
-archives, while GNU @code{tar} currently also store @code{atime}
-and @code{ctime}. If we want GNU @code{tar} to go closer to POSIX,
-my choice would be to drop @code{atime} and @code{ctime} support on
-average. On the other hand, I perceive that full dumps or incremental
-dumps need @code{atime} and @code{ctime} support, so for those special
-applications, POSIX has to be avoided altogether.
-
-A few users requested that @value{op-sparse} be always active by
-default, I think that before replying to them, we have to decide
-if we want GNU @code{tar} to go closer to POSIX on average, while
-producing files. My choice would be to go closer to POSIX in the
-long run. Besides possible double reading, I do not see any point
-of not trying to save files as sparse when creating archives which
-are neither POSIX nor old-V7, so the actual @value{op-sparse} would
-become selected by default when producing such archives, whatever
-the reason is. So, @value{op-sparse} alone might be redefined to force
-GNU-format archives, and recover its previous meaning from this fact.
-
-GNU-format as it exists now can easily fool other POSIX @code{tar},
-as it uses fields which POSIX considers to be part of the file name
-prefix. I wonder if it would not be a good idea, in the long run,
-to try changing GNU-format so any added field (like @code{ctime},
-@code{atime}, file offset in subsequent volumes, or sparse file
-descriptions) be wholly and always pushed into an extension block,
-instead of using space in the POSIX header block. I could manage
-to do that portably between future GNU @code{tar}s. So other POSIX
-@code{tar}s might be at least able to provide kind of correct listings
-for the archives produced by GNU @code{tar}, if not able to process
-them otherwise.
-
-Using these projected extensions might induce older @code{tar}s to fail.
-We would use the same approach as for POSIX. I'll put out a @code{tar}
-capable of reading POSIXier, yet extended archives, but will not produce
-this format by default, in GNU mode. In a few years, when newer GNU
-@code{tar}s will have flooded out @code{tar} 1.11.X and previous, we
-could switch to producing POSIXier extended archives, with no real harm
-to users, as almost all existing GNU @code{tar}s will be ready to read
-POSIXier format. In fact, I'll do both changes at the same time, in a
-few years, and just prepare @code{tar} for both changes, without effecting
-them, from 1.@var{POSIX}. (Both changes: 1---using POSIX convention for
-getting over 100 characters; 2---avoiding mangling POSIX headers for GNU
-extensions, using only POSIX mandated extension techniques).
-
-So, a future @code{tar} will have a @value{op-posix}
-flag forcing the usage of truly POSIX headers, and so, producing
-archives previous GNU @code{tar} will not be able to read.
-So, @emph{once} pretest will announce that feature, it would be
-particularly useful that users test how exchangeable will be archives
-between GNU @code{tar} with @value{op-posix} and other POSIX @code{tar}.
-
-In a few years, when GNU @code{tar} will produce POSIX headers by
-default, @value{op-posix} will have a strong meaning and will disallow
-GNU extensions. But in the meantime, for a long while, @value{op-posix}
-in GNU tar will not disallow GNU extensions like @value{op-label},
-@value{op-multi-volume}, @value{op-sparse}, or very long file or link names.
-However, @value{op-posix} with GNU extensions will use POSIX
-headers with reserved-for-users extensions to headers, and I will be
-curious to know how well or bad POSIX @code{tar}s will react to these.
-
-GNU @code{tar} prior to 1.@var{POSIX}, and after 1.@var{POSIX} without
-@value{op-posix}, generates and checks @samp{ustar@w{ }@w{ }}, with two
-suffixed spaces. This is sufficient for older GNU @code{tar} not to
-recognize POSIX archives, and consequently, wrongly decide those archives
-are in old V7 format. It is a useful bug for me, because GNU @code{tar}
-has other POSIX incompatibilities, and I need to segregate GNU @code{tar}
-semi-POSIX archives from truly POSIX archives, for GNU @code{tar} should
-be somewhat compatible with itself, while migrating closer to latest
-POSIX standards. So, I'll be very careful about how and when I will do
-the correction.
-
-@node Checksumming, , posix, Portability
-@subsection Checksumming Problems
+@smallexample
+$ @kbd{tar --transform 's/.*/\L&/' -x -f arch.tar}
+@end smallexample
+
+@end enumerate
+
+Unlike @option{--strip-components}, @option{--transform} can be used
+in any @GNUTAR{} operation mode. For example, the following command
+adds files to the archive while replacing the leading @file{usr/}
+component with @file{var/}:
+
+@smallexample
+$ @kbd{tar -cf arch.tar --transform='s,^usr/,var/,' /}
+@end smallexample
+
+To test @option{--transform} effect we suggest using
+@option{--show-transformed-names} option:
+
+@smallexample
+$ @kbd{tar -cf arch.tar --transform='s,^usr/,var/,' \
+ --verbose --show-transformed-names /}
+@end smallexample
+
+If both @option{--strip-components} and @option{--transform} are used
+together, then @option{--transform} is applied first, and the required
+number of components is then stripped from its result.
+
+@node after
+@section Operating Only on New Files
+@UNREVISED
+
+@cindex Excluding file by age
+@cindex Data Modification time, excluding files by
+@cindex Modification time, excluding files by
+@cindex Age, excluding files by
+The @option{--after-date=@var{date}} (@option{--newer=@var{date}},
+@option{-N @var{date}}) option causes @command{tar} to only work on
+files whose data modification or status change times are newer than
+the @var{date} given. If @var{date} starts with @samp{/} or @samp{.},
+it is taken to be a file name; the data modification time of that file
+is used as the date. If you use this option when creating or appending
+to an archive, the archive will only include new files. If you use
+@option{--after-date} when extracting an archive, @command{tar} will
+only extract files newer than the @var{date} you specify.
+
+If you only want @command{tar} to make the date comparison based on
+modification of the file's data (rather than status
+changes), then use the @option{--newer-mtime=@var{date}} option.
+
+You may use these options with any operation. Note that these options
+differ from the @option{--update} (@option{-u}) operation in that they
+allow you to specify a particular date against which @command{tar} can
+compare when deciding whether or not to archive the files.
+
+@table @option
+@opindex after-date
+@opindex newer
+@item --after-date=@var{date}
+@itemx --newer=@var{date}
+@itemx -N @var{date}
+Only store files newer than @var{date}.
+
+Acts on files only if their data modification or status change times are
+later than @var{date}. Use in conjunction with any operation.
+
+If @var{date} starts with @samp{/} or @samp{.}, it is taken to be a file
+name; the data modification time of that file is used as the date.
+
+@opindex newer-mtime
+@item --newer-mtime=@var{date}
+Acts like @option{--after-date}, but only looks at data modification times.
+@end table
+
+These options limit @command{tar} to operate only on files which have
+been modified after the date specified. A file's status is considered to have
+changed if its contents have been modified, or if its owner,
+permissions, and so forth, have been changed. (For more information on
+how to specify a date, see @ref{Date input formats}; remember that the
+entire date argument must be quoted if it contains any spaces.)
+
+Gurus would say that @option{--after-date} tests both the data
+modification time (@code{mtime}, the time the contents of the file
+were last modified) and the status change time (@code{ctime}, the time
+the file's status was last changed: owner, permissions, etc.@:)
+fields, while @option{--newer-mtime} tests only the @code{mtime}
+field.
+
+To be precise, @option{--after-date} checks @emph{both} @code{mtime} and
+@code{ctime} and processes the file if either one is more recent than
+@var{date}, while @option{--newer-mtime} only checks @code{mtime} and
+disregards @code{ctime}. Neither does it use @code{atime} (the last time the
+contents of the file were looked at).
+
+Date specifiers can have embedded spaces. Because of this, you may need
+to quote date arguments to keep the shell from parsing them as separate
+arguments. For example, the following command will add to the archive
+all the files modified less than two days ago:
+
+@smallexample
+$ @kbd{tar -cf foo.tar --newer-mtime '2 days ago'}
+@end smallexample
+
+When any of these options is used with the option @option{--verbose}
+(@pxref{verbose tutorial}) @GNUTAR{} will try to convert the specified
+date back to its textual representation and compare that with the
+one given with the option. If the two dates differ, @command{tar} will
+print a warning saying what date it will use. This is to help user
+ensure he is using the right date. For example:
+
+@smallexample
+@group
+$ @kbd{tar -c -f archive.tar --after-date='10 days ago' .}
+tar: Option --after-date: Treating date `10 days ago' as 2006-06-11
+13:19:37.232434
+@end group
+@end smallexample
+
+@quotation
+@strong{Please Note:} @option{--after-date} and @option{--newer-mtime}
+should not be used for incremental backups. @xref{Incremental Dumps},
+for proper way of creating incremental backups.
+@end quotation
+
+@node recurse
+@section Descending into Directories
+@UNREVISED
+@cindex Avoiding recursion in directories
+@cindex Descending directories, avoiding
+@cindex Directories, avoiding recursion
+@cindex Recursion in directories, avoiding
+
+@FIXME{arrggh! this is still somewhat confusing to me. :-< }
+
+Usually, @command{tar} will recursively explore all directories (either
+those given on the command line or through the @option{--files-from}
+option) for the various files they contain. However, you may not always
+want @command{tar} to act this way.
+
+@opindex no-recursion
+The @option{--no-recursion} option inhibits @command{tar}'s recursive descent
+into specified directories. If you specify @option{--no-recursion}, you can
+use the @command{find} utility for hunting through levels of directories to
+construct a list of file names which you could then pass to @command{tar}.
+@command{find} allows you to be more selective when choosing which files to
+archive; see @ref{files}, for more information on using @command{find} with
+@command{tar}, or look.
+
+@table @option
+@item --no-recursion
+Prevents @command{tar} from recursively descending directories.
+
+@opindex recursion
+@item --recursion
+Requires @command{tar} to recursively descend directories.
+This is the default.
+@end table
+
+When you use @option{--no-recursion}, @GNUTAR{} grabs
+directory entries themselves, but does not descend on them
+recursively. Many people use @command{find} for locating files they
+want to back up, and since @command{tar} @emph{usually} recursively
+descends on directories, they have to use the @samp{@w{-not -type d}}
+test in their @command{find} invocation (@pxref{Type, Type, Type test,
+find, Finding Files}), as they usually do not want all the files in a
+directory. They then use the @option{--files-from} option to archive
+the files located via @command{find}.
+
+The problem when restoring files archived in this manner is that the
+directories themselves are not in the archive; so the
+@option{--same-permissions} (@option{--preserve-permissions},
+@option{-p}) option does not affect them---while users might really
+like it to. Specifying @option{--no-recursion} is a way to tell
+@command{tar} to grab only the directory entries given to it, adding
+no new files on its own. To summarize, if you use @command{find} to
+create a list of files to be stored in an archive, use it as follows:
+
+@smallexample
+@group
+$ @kbd{find @var{dir} @var{tests} | \
+ tar -cf @var{archive} -T - --no-recursion}
+@end group
+@end smallexample
+
+The @option{--no-recursion} option also applies when extracting: it
+causes @command{tar} to extract only the matched directory entries, not
+the files under those directories.
+
+The @option{--no-recursion} option also affects how globbing patterns
+are interpreted (@pxref{controlling pattern-matching}).
+
+The @option{--no-recursion} and @option{--recursion} options apply to
+later options and operands, and can be overridden by later occurrences
+of @option{--no-recursion} and @option{--recursion}. For example:
+
+@smallexample
+$ @kbd{tar -cf jams.tar --no-recursion grape --recursion grape/concord}
+@end smallexample
+
+@noindent
+creates an archive with one entry for @file{grape}, and the recursive
+contents of @file{grape/concord}, but no entries under @file{grape}
+other than @file{grape/concord}.
+
+@node one
+@section Crossing File System Boundaries
+@cindex File system boundaries, not crossing
+@UNREVISED
+
+@command{tar} will normally automatically cross file system boundaries in
+order to archive files which are part of a directory tree. You can
+change this behavior by running @command{tar} and specifying
+@option{--one-file-system}. This option only affects files that are
+archived because they are in a directory that is being archived;
+@command{tar} will still archive files explicitly named on the command line
+or through @option{--files-from}, regardless of where they reside.
+
+@table @option
+@opindex one-file-system
+@item --one-file-system
+Prevents @command{tar} from crossing file system boundaries when
+archiving. Use in conjunction with any write operation.
+@end table
+
+The @option{--one-file-system} option causes @command{tar} to modify its
+normal behavior in archiving the contents of directories. If a file in
+a directory is not on the same file system as the directory itself, then
+@command{tar} will not archive that file. If the file is a directory
+itself, @command{tar} will not archive anything beneath it; in other words,
+@command{tar} will not cross mount points.
+
+This option is useful for making full or incremental archival backups of
+a file system. If this option is used in conjunction with
+@option{--verbose} (@option{-v}), files that are excluded are
+mentioned by name on the standard error.
+
+@menu
+* directory:: Changing Directory
+* absolute:: Absolute File Names
+@end menu
+
+@node directory
+@subsection Changing the Working Directory
+
+@FIXME{need to read over this node now for continuity; i've switched
+things around some.}
+
+@cindex Changing directory mid-stream
+@cindex Directory, changing mid-stream
+@cindex Working directory, specifying
+To change the working directory in the middle of a list of file names,
+either on the command line or in a file specified using
+@option{--files-from} (@option{-T}), use @option{--directory} (@option{-C}).
+This will change the working directory to the specified directory
+after that point in the list.
+
+@table @option
+@opindex directory
+@item --directory=@var{directory}
+@itemx -C @var{directory}
+Changes the working directory in the middle of a command line.
+@end table
+
+For example,
+
+@smallexample
+$ @kbd{tar -c -f jams.tar grape prune -C food cherry}
+@end smallexample
+
+@noindent
+will place the files @file{grape} and @file{prune} from the current
+directory into the archive @file{jams.tar}, followed by the file
+@file{cherry} from the directory @file{food}. This option is especially
+useful when you have several widely separated files that you want to
+store in the same archive.
+
+Note that the file @file{cherry} is recorded in the archive under the
+precise name @file{cherry}, @emph{not} @file{food/cherry}. Thus, the
+archive will contain three files that all appear to have come from the
+same directory; if the archive is extracted with plain @samp{tar
+--extract}, all three files will be written in the current directory.
+
+Contrast this with the command,
+
+@smallexample
+$ @kbd{tar -c -f jams.tar grape prune -C food red/cherry}
+@end smallexample
+
+@noindent
+which records the third file in the archive under the name
+@file{red/cherry} so that, if the archive is extracted using
+@samp{tar --extract}, the third file will be written in a subdirectory
+named @file{orange-colored}.
+
+You can use the @option{--directory} option to make the archive
+independent of the original name of the directory holding the files.
+The following command places the files @file{/etc/passwd},
+@file{/etc/hosts}, and @file{/lib/libc.a} into the archive
+@file{foo.tar}:
+
+@smallexample
+$ @kbd{tar -c -f foo.tar -C /etc passwd hosts -C /lib libc.a}
+@end smallexample
+
+@noindent
+However, the names of the archive members will be exactly what they were
+on the command line: @file{passwd}, @file{hosts}, and @file{libc.a}.
+They will not appear to be related by file name to the original
+directories where those files were located.
+
+Note that @option{--directory} options are interpreted consecutively. If
+@option{--directory} specifies a relative file name, it is interpreted
+relative to the then current directory, which might not be the same as
+the original current working directory of @command{tar}, due to a previous
+@option{--directory} option.
+
+When using @option{--files-from} (@pxref{files}), you can put various
+@command{tar} options (including @option{-C}) in the file list. Notice,
+however, that in this case the option and its argument may not be
+separated by whitespace. If you use short option, its argument must
+either follow the option letter immediately, without any intervening
+whitespace, or occupy the next line. Otherwise, if you use long
+option, separate its argument by an equal sign.
+
+For instance, the file list for the above example will be:
+
+@smallexample
+@group
+-C/etc
+passwd
+hosts
+--directory=/lib
+libc.a
+@end group
+@end smallexample
+
+@noindent
+To use it, you would invoke @command{tar} as follows:
+
+@smallexample
+$ @kbd{tar -c -f foo.tar --files-from list}
+@end smallexample
+
+The interpretation of @option{--directory} is disabled by
+@option{--null} option.
+
+@node absolute
+@subsection Absolute File Names
+@UNREVISED
+
+@table @option
+@opindex absolute-names
+@item --absolute-names
+@itemx -P
+Do not strip leading slashes from file names, and permit file names
+containing a @file{..} file name component.
+@end table
+
+By default, @GNUTAR{} drops a leading @samp{/} on
+input or output, and complains about file names containing a @file{..}
+component. This option turns off this behavior.
+
+When @command{tar} extracts archive members from an archive, it strips any
+leading slashes (@samp{/}) from the member name. This causes absolute
+member names in the archive to be treated as relative file names. This
+allows you to have such members extracted wherever you want, instead of
+being restricted to extracting the member in the exact directory named
+in the archive. For example, if the archive member has the name
+@file{/etc/passwd}, @command{tar} will extract it as if the name were
+really @file{etc/passwd}.
+
+File names containing @file{..} can cause problems when extracting, so
+@command{tar} normally warns you about such files when creating an
+archive, and rejects attempts to extracts such files.
+
+Other @command{tar} programs do not do this. As a result, if you
+create an archive whose member names start with a slash, they will be
+difficult for other people with a non-@GNUTAR{}
+program to use. Therefore, @GNUTAR{} also strips
+leading slashes from member names when putting members into the
+archive. For example, if you ask @command{tar} to add the file
+@file{/bin/ls} to an archive, it will do so, but the member name will
+be @file{bin/ls}.@footnote{A side effect of this is that when
+@option{--create} is used with @option{--verbose} the resulting output
+is not, generally speaking, the same as the one you'd get running
+@kbd{tar --list} command. This may be important if you use some
+scripts for comparing both outputs. @xref{listing member and file names},
+for the information on how to handle this case.}
+
+If you use the @option{--absolute-names} (@option{-P}) option,
+@command{tar} will do none of these transformations.
+
+To archive or extract files relative to the root directory, specify
+the @option{--absolute-names} (@option{-P}) option.
+
+Normally, @command{tar} acts on files relative to the working
+directory---ignoring superior directory names when archiving, and
+ignoring leading slashes when extracting.
+
+When you specify @option{--absolute-names} (@option{-P}),
+@command{tar} stores file names including all superior directory
+names, and preserves leading slashes. If you only invoked
+@command{tar} from the root directory you would never need the
+@option{--absolute-names} option, but using this option
+may be more convenient than switching to root.
+
+@FIXME{Should be an example in the tutorial/wizardry section using this
+to transfer files between systems.}
+
+@FIXME{Is write access an issue?}
+
+@table @option
+@item --absolute-names
+Preserves full file names (including superior directory names) when
+archiving files. Preserves leading slash when extracting files.
+
+@end table
+
+@FIXME{this is still horrible; need to talk with dan on monday.}
+
+@command{tar} prints out a message about removing the @samp{/} from
+file names. This message appears once per @GNUTAR{}
+invocation. It represents something which ought to be told; ignoring
+what it means can cause very serious surprises, later.
+
+Some people, nevertheless, do not want to see this message. Wanting to
+play really dangerously, one may of course redirect @command{tar} standard
+error to the sink. For example, under @command{sh}:
+
+@smallexample
+$ @kbd{tar -c -f archive.tar /home 2> /dev/null}
+@end smallexample
+
+@noindent
+Another solution, both nicer and simpler, would be to change to
+the @file{/} directory first, and then avoid absolute notation.
+For example:
+
+@smallexample
+$ @kbd{(cd / && tar -c -f archive.tar home)}
+# @i{or}:
+$ @kbd{tar -c -f archive.tar -C / home}
+@end smallexample
+
+@include getdate.texi
+
+@node Formats
+@chapter Controlling the Archive Format
+
+@cindex Tar archive formats
+Due to historical reasons, there are several formats of tar archives.
+All of them are based on the same principles, but have some subtle
+differences that often make them incompatible with each other.
+
+GNU tar is able to create and handle archives in a variety of formats.
+The most frequently used formats are (in alphabetical order):
+
+@table @asis
+@item gnu
+Format used by @GNUTAR{} versions up to 1.13.25. This format derived
+from an early @acronym{POSIX} standard, adding some improvements such as
+sparse file handling and incremental archives. Unfortunately these
+features were implemented in a way incompatible with other archive
+formats.
+
+Archives in @samp{gnu} format are able to hold file names of unlimited
+length.
+
+@item oldgnu
+Format used by @GNUTAR{} of versions prior to 1.12.
+
+@item v7
+Archive format, compatible with the V7 implementation of tar. This
+format imposes a number of limitations. The most important of them
+are:
+
+@enumerate
+@item The maximum length of a file name is limited to 99 characters.
+@item The maximum length of a symbolic link is limited to 99 characters.
+@item It is impossible to store special files (block and character
+devices, fifos etc.)
+@item Maximum value of user or group @acronym{ID} is limited to 2097151 (7777777
+octal)
+@item V7 archives do not contain symbolic ownership information (user
+and group name of the file owner).
+@end enumerate
+
+This format has traditionally been used by Automake when producing
+Makefiles. This practice will change in the future, in the meantime,
+however this means that projects containing file names more than 99
+characters long will not be able to use @GNUTAR{} @value{VERSION} and
+Automake prior to 1.9.
+
+@item ustar
+Archive format defined by @acronym{POSIX.1-1988} specification. It stores
+symbolic ownership information. It is also able to store
+special files. However, it imposes several restrictions as well:
+
+@enumerate
+@item The maximum length of a file name is limited to 256 characters,
+provided that the file name can be split at a directory separator in
+two parts, first of them being at most 155 bytes long. So, in most
+cases the maximum file name length will be shorter than 256
+characters.
+@item The maximum length of a symbolic link name is limited to
+100 characters.
+@item Maximum size of a file the archive is able to accommodate
+is 8GB
+@item Maximum value of UID/GID is 2097151.
+@item Maximum number of bits in device major and minor numbers is 21.
+@end enumerate
+
+@item star
+Format used by J@"org Schilling @command{star}
+implementation. @GNUTAR{} is able to read @samp{star} archives but
+currently does not produce them.
+
+@item posix
+Archive format defined by @acronym{POSIX.1-2001} specification. This is the
+most flexible and feature-rich format. It does not impose any
+restrictions on file sizes or file name lengths. This format is quite
+recent, so not all tar implementations are able to handle it properly.
+However, this format is designed in such a way that any tar
+implementation able to read @samp{ustar} archives will be able to read
+most @samp{posix} archives as well, with the only exception that any
+additional information (such as long file names etc.) will in such
+case be extracted as plain text files along with the files it refers to.
+
+This archive format will be the default format for future versions
+of @GNUTAR{}.
+
+@end table
+
+The following table summarizes the limitations of each of these
+formats:
+
+@multitable @columnfractions .10 .20 .20 .20 .20
+@headitem Format @tab UID @tab File Size @tab File Name @tab Devn
+@item gnu @tab 1.8e19 @tab Unlimited @tab Unlimited @tab 63
+@item oldgnu @tab 1.8e19 @tab Unlimited @tab Unlimited @tab 63
+@item v7 @tab 2097151 @tab 8GB @tab 99 @tab n/a
+@item ustar @tab 2097151 @tab 8GB @tab 256 @tab 21
+@item posix @tab Unlimited @tab Unlimited @tab Unlimited @tab Unlimited
+@end multitable
+
+The default format for @GNUTAR{} is defined at compilation
+time. You may check it by running @command{tar --help}, and examining
+the last lines of its output. Usually, @GNUTAR{} is configured
+to create archives in @samp{gnu} format, however, future version will
+switch to @samp{posix}.
+
+@menu
+* Compression:: Using Less Space through Compression
+* Attributes:: Handling File Attributes
+* Portability:: Making @command{tar} Archives More Portable
+* cpio:: Comparison of @command{tar} and @command{cpio}
+@end menu
+
+@node Compression
+@section Using Less Space through Compression
+
+@menu
+* gzip:: Creating and Reading Compressed Archives
+* sparse:: Archiving Sparse Files
+@end menu
+
+@node gzip
+@subsection Creating and Reading Compressed Archives
+@cindex Compressed archives
+@cindex Storing archives in compressed format
+
+@GNUTAR{} is able to create and read compressed archives. It supports
+@command{gzip} and @command{bzip2} compression programs. For backward
+compatibility, it also supports @command{compress} command, although
+we strongly recommend against using it, since there is a patent
+covering the algorithm it uses and you could be sued for patent
+infringement merely by running @command{compress}! Besides, it is less
+effective than @command{gzip} and @command{bzip2}.
+
+Creating a compressed archive is simple: you just specify a
+@dfn{compression option} along with the usual archive creation
+commands. The compression option is @option{-z} (@option{--gzip}) to
+create a @command{gzip} compressed archive, @option{-j}
+(@option{--bzip2}) to create a @command{bzip2} compressed archive, and
+@option{-Z} (@option{--compress}) to use @command{compress} program.
+For example:
+
+@smallexample
+$ @kbd{tar cfz archive.tar.gz .}
+@end smallexample
+
+Reading compressed archive is even simpler: you don't need to specify
+any additional options as @GNUTAR{} recognizes its format
+automatically. Thus, the following commands will list and extract the
+archive created in previous example:
+
+@smallexample
+# List the compressed archive
+$ @kbd{tar tf archive.tar.gz}
+# Extract the compressed archive
+$ @kbd{tar xf archive.tar.gz}
+@end smallexample
+
+The only case when you have to specify a decompression option while
+reading the archive is when reading from a pipe or from a tape drive
+that does not support random access. However, in this case @GNUTAR{}
+will indicate which option you should use. For example:
+
+@smallexample
+$ @kbd{cat archive.tar.gz | tar tf -}
+tar: Archive is compressed. Use -z option
+tar: Error is not recoverable: exiting now
+@end smallexample