+@FIXME{This about backup scripts needs to be written: BS is a shell
+script .... thus ... @file{backup-specs} is in shell script syntax.}
+
+@FIXME-xref{Script Syntax, for an explanation of this syntax.}
+
+@FIXME{Whats a parameter .... looked at by the backup scripts
+... which will be expecting to find ... now syntax ... value is linked
+to lame ... @file{backup-specs} specifies the following parameters:}
+
+@table @samp
+@item ADMINISTRATOR
+The user name of the backup administrator.
+
+@item BACKUP_HOUR
+The hour at which the backups are done. This can be a number from 0
+to 23, or the string @samp{now}.
+
+@item TAPE_FILE
+The device @command{tar} writes the archive to. This device should be
+attached to the host on which the dump scripts are run.
+
+@FIXME{examples for all ...}
+
+@item TAPE_STATUS
+The command to use to obtain the status of the archive device,
+including error count. On some tape drives there may not be such a
+command; in that case, simply use @samp{TAPE_STATUS=false}.
+
+@item BLOCKING
+The blocking factor @command{tar} will use when writing the dump archive.
+@value{xref-blocking-factor}.
+
+@item BACKUP_DIRS
+A list of file systems to be dumped. You can include any directory
+name in the list---subdirectories on that file system will be
+included, regardless of how they may look to other networked machines.
+Subdirectories on other file systems will be ignored.
+
+The host name specifies which host to run @command{tar} on, and should
+normally be the host that actually contains the file system. However,
+the host machine must have @acronym{GNU} @command{tar} installed, and
+must be able to access the directory containing the backup scripts and
+their support files using the same file name that is used on the
+machine where the scripts are run (ie. what @command{pwd} will print
+when in that directory on that machine). If the host that contains
+the file system does not have this capability, you can specify another
+host as long as it can access the file system through NFS.
+
+@item BACKUP_FILES
+A list of individual files to be dumped. These should be accessible
+from the machine on which the backup script is run.
+
+@FIXME{Same file name, be specific. Through NFS ...}
+
+@end table
+
+@menu
+* backup-specs example:: An Example Text of @file{Backup-specs}
+* Script Syntax:: Syntax for @file{Backup-specs}
+@end menu
+
+@node backup-specs example
+@subsection An Example Text of @file{Backup-specs}
+@UNREVISED
+
+The following is the text of @file{backup-specs} as it appears at FSF:
+
+@example
+# site-specific parameters for file system backup.
+
+ADMINISTRATOR=friedman
+BACKUP_HOUR=1
+TAPE_FILE=/dev/nrsmt0
+TAPE_STATUS="mts -t $TAPE_FILE"
+BLOCKING=124
+BACKUP_DIRS="
+ albert:/fs/fsf
+ apple-gunkies:/gd
+ albert:/fs/gd2
+ albert:/fs/gp
+ geech:/usr/jla
+ churchy:/usr/roland
+ albert:/
+ albert:/usr
+ apple-gunkies:/
+ apple-gunkies:/usr
+ gnu:/hack
+ gnu:/u
+ apple-gunkies:/com/mailer/gnu
+ apple-gunkies:/com/archive/gnu"
+
+BACKUP_FILES="/com/mailer/aliases /com/mailer/league*[a-z]"
+
+@end example
+
+@node Script Syntax
+@subsection Syntax for @file{Backup-specs}
+@UNREVISED
+
+@file{backup-specs} is in shell script syntax. The following
+conventions should be considered when editing the script:
+@FIXME{"conventions?"}
+
+A quoted string is considered to be contiguous, even if it is on more
+than one line. Therefore, you cannot include commented-out lines
+within a multi-line quoted string. BACKUP_FILES and BACKUP_DIRS are
+the two most likely parameters to be multi-line.
+
+A quoted string typically cannot contain wildcards. In
+@file{backup-specs}, however, the parameters BACKUP_DIRS and
+BACKUP_FILES can contain wildcards.
+
+@node Scripted Backups
+@section Using the Backup Scripts
+@UNREVISED
+
+The syntax for running a backup script is:
+
+@example
+@file{script-name} [@var{time-to-be-run}]
+@end example
+
+where @var{time-to-be-run} can be a specific system time, or can be
+@kbd{now}. If you do not specify a time, the script runs at the time
+specified in @file{backup-specs}. @FIXME-pxref{Script Syntax}
+
+You should start a script with a tape or disk mounted. Once you
+start a script, it prompts you for new tapes or disks as it
+needs them. Media volumes don't have to correspond to archive
+files---a multi-volume archive can be started in the middle of a
+tape that already contains the end of another multi-volume archive.
+The @code{restore} script prompts for media by its archive volume,
+so to avoid an error message you should keep track of which tape
+(or disk) contains which volume of the archive. @FIXME{There is
+no such restore script!} @FIXME-xref{Scripted Restoration}
+@FIXME{Have file names changed?}
+
+The backup scripts write two files on the file system. The first is a
+record file in @file{/etc/tar-backup/}, which is used by the scripts
+to store and retrieve information about which files were dumped. This
+file is not meant to be read by humans, and should not be deleted by
+them. @FIXME-xref{incremental and listed-incremental, for a more
+detailed explanation of this file.}
+
+The second file is a log file containing the names of the file systems
+and files dumped, what time the backup was made, and any error
+messages that were generated, as well as how much space was left in
+the media volume after the last volume of the archive was written.
+You should check this log file after every backup. The file name is
+@file{log-@var{mmm-ddd-yyyy}-level-1} or
+@file{log-@var{mmm-ddd-yyyy}-full}.
+
+The script also prints the name of each system being dumped to the
+standard output.
+
+@node Scripted Restoration
+@section Using the Restore Script
+@UNREVISED
+
+@ifset PUBLISH
+
+The @command{tar} distribution does not provide restoring scripts.
+
+@end ifset
+
+@ifclear PUBLISH
+
+@quotation
+@strong{Warning:} The @acronym{GNU} @command{tar} distribution does @emph{not}
+provide any such @code{restore} script yet. This section is only
+listed here for documentation maintenance purposes. In any case,
+all contents is subject to change as things develop.
+@end quotation
+
+@FIXME{A section on non-scripted restore may be a good idea.}
+
+To restore files that were archived using a scripted backup, use the
+@code{restore} script. The syntax for the script is:
+
+where ***** are the file systems to restore from, and
+***** is a regular expression which specifies which files to
+restore. If you specify --all, the script restores all the files
+in the file system.
+
+You should start the restore script with the media containing the
+first volume of the archive mounted. The script will prompt for other
+volumes as they are needed. If the archive is on tape, you don't need
+to rewind the tape to to its beginning---if the tape head is
+positioned past the beginning of the archive, the script will rewind
+the tape as needed. @FIXME-xref{Media, for a discussion of tape
+positioning.}
+
+If you specify @samp{--all} as the @var{files} argument, the
+@code{restore} script extracts all the files in the archived file
+system into the active file system.
+
+@quotation
+@strong{Warning:} The script will delete files from the active file
+system if they were not in the file system when the archive was made.
+@end quotation
+
+@value{xref-incremental}, and @value{ref-listed-incremental},
+for an explanation of how the script makes that determination.
+
+@FIXME{this may be an option, not a given}
+
+@end ifclear
+
+@node Choosing
+@chapter Choosing Files and Names for @command{tar}
+@UNREVISED
+
+@FIXME{Melissa (still) Doesn't Really Like This ``Intro'' Paragraph!!!}
+
+Certain options to @command{tar} enable you to specify a name for your
+archive. Other options let you decide which files to include or exclude
+from the archive, based on when or whether files were modified, whether
+the file names do or don't match specified patterns, or whether files
+are in specified directories.
+
+@menu
+* file:: Choosing the Archive's Name
+* Selecting Archive Members::
+* files:: Reading Names from a File
+* exclude:: Excluding Some Files
+* Wildcards::
+* after:: Operating Only on New Files
+* recurse:: Descending into Directories
+* one:: Crossing Filesystem Boundaries
+@end menu
+
+@node file
+@section Choosing and Naming Archive Files
+@cindex Naming an archive
+@cindex Archive Name
+@cindex Directing output
+@cindex Choosing an archive file
+@cindex Where is the archive?
+@UNREVISED
+
+@FIXME{should the title of this section actually be, "naming an
+archive"?}
+
+By default, @command{tar} uses an archive file name that was compiled when
+it was built on the system; usually this name refers to some physical
+tape drive on the machine. However, the person who installed @command{tar}
+on the system may not set the default to a meaningful value as far as
+most users are concerned. As a result, you will usually want to tell
+@command{tar} where to find (or create) the archive. The @value{op-file}
+option allows you to either specify or name a file to use as the archive
+instead of the default archive file location.
+
+@table @kbd
+@item --file=@var{archive-name}
+@itemx -f @var{archive-name}
+Name the archive to create or operate on. Use in conjunction with
+any operation.
+@end table
+
+For example, in this @command{tar} command,
+
+@example
+$ @kbd{tar -cvf collection.tar blues folk jazz}
+@end example
+
+@noindent
+@file{collection.tar} is the name of the archive. It must directly
+follow the @samp{-f} option, since whatever directly follows @samp{-f}
+@emph{will} end up naming the archive. If you neglect to specify an
+archive name, you may end up overwriting a file in the working directory
+with the archive you create since @command{tar} will use this file's name
+for the archive name.
+
+An archive can be saved as a file in the file system, sent through a
+pipe or over a network, or written to an I/O device such as a tape,
+floppy disk, or CD write drive.
+
+@cindex Writing new archives
+@cindex Archive creation
+If you do not name the archive, @command{tar} uses the value of the
+environment variable @env{TAPE} as the file name for the archive. If
+that is not available, @command{tar} uses a default, compiled-in archive
+name, usually that for tape unit zero (ie. @file{/dev/tu00}).
+@command{tar} always needs an archive name.
+
+If you use @file{-} as an @var{archive-name}, @command{tar} reads the
+archive from standard input (when listing or extracting files), or
+writes it to standard output (when creating an archive). If you use
+@file{-} as an @var{archive-name} when modifying an archive,
+@command{tar} reads the original archive from its standard input and
+writes the entire new archive to its standard output.
+
+@FIXME{might want a different example here; this is already used in
+"notable tar usages".}
+
+@example
+$ @kbd{cd sourcedir; tar -cf - . | (cd targetdir; tar -xf -)}
+@end example
+
+@FIXME{help!}
+
+@cindex Standard input and output
+@cindex tar to standard input and output
+To specify an archive file on a device attached to a remote machine,
+use the following:
+
+@example
+@kbd{--file=@var{hostname}:/@var{dev}/@var{file name}}
+@end example
+
+@noindent
+@command{tar} will complete the remote connection, if possible, and
+prompt you for a username and password. If you use
+@samp{--file=@@@var{hostname}:/@var{dev}/@var{file name}}, @command{tar}
+will complete the remote connection, if possible, using your username
+as the username on the remote machine.
+
+If the archive file name includes a colon (@samp{:}), then it is assumed
+to be a file on another machine. If the archive file is
+@samp{@var{user}@@@var{host}:@var{file}}, then @var{file} is used on the
+host @var{host}. The remote host is accessed using the @command{rsh}
+program, with a username of @var{user}. If the username is omitted
+(along with the @samp{@@} sign), then your user name will be used.
+(This is the normal @command{rsh} behavior.) It is necessary for the
+remote machine, in addition to permitting your @command{rsh} access, to
+have the @file{/usr/ucb/rmt} program installed. If you need to use a
+file whose name includes a colon, then the remote tape drive behavior
+can be inhibited by using the @value{op-force-local} option.
+
+@FIXME{i know we went over this yesterday, but bob (and now i do again,
+too) thinks it's out of the middle of nowhere. it doesn't seem to tie
+into what came before it well enough <<i moved it now, is it better
+here?>>. bob also comments that if Amanda isn't free software, we
+shouldn't mention it..}
+
+When the archive is being created to @file{/dev/null}, @acronym{GNU}
+@command{tar} tries to minimize input and output operations. The
+Amanda backup system, when used with @acronym{GNU} @command{tar}, has
+an initial sizing pass which uses this feature.
+
+@node Selecting Archive Members
+@section Selecting Archive Members
+@cindex Specifying files to act on
+@cindex Specifying archive members
+
+@dfn{File Name arguments} specify which files in the file system
+@command{tar} operates on, when creating or adding to an archive, or which
+archive members @command{tar} operates on, when reading or deleting from
+an archive. @xref{Operations}.
+
+To specify file names, you can include them as the last arguments on
+the command line, as follows:
+@smallexample
+@kbd{tar} @var{operation} [@var{option1} @var{option2} @dots{}] [@var{file name-1} @var{file name-2} @dots{}]
+@end smallexample
+
+If you specify a directory name as a file name argument, all the files
+in that directory are operated on by @command{tar}.
+
+If you do not specify files when @command{tar} is invoked with
+@value{op-create}, @command{tar} operates on all the non-directory files in
+the working directory. If you specify either @value{op-list} or
+@value{op-extract}, @command{tar} operates on all the archive members in the
+archive. If you specify any operation other than one of these three,
+@command{tar} does nothing.
+
+By default, @command{tar} takes file names from the command line. However,
+there are other ways to specify file or member names, or to modify the
+manner in which @command{tar} selects the files or members upon which to
+operate. @FIXME{add xref here}In general, these methods work both for
+specifying the names of files and archive members.
+
+@node files
+@section Reading Names from a File
+@UNREVISED
+
+@cindex Reading file names from a file
+@cindex Lists of file names
+@cindex File Name arguments, alternatives
+Instead of giving the names of files or archive members on the command
+line, you can put the names into a file, and then use the
+@value{op-files-from} option to @command{tar}. Give the name of the file
+which contains the list of files to include as the argument to
+@samp{--files-from}. In the list, the file names should be separated by
+newlines. You will frequently use this option when you have generated
+the list of files to archive with the @command{find} utility.
+
+@table @kbd
+@item --files-from=@var{file name}
+@itemx -T @var{file name}
+Get names to extract or create from file @var{file name}.
+@end table
+
+If you give a single dash as a file name for @samp{--files-from}, (i.e.,
+you specify either @samp{--files-from=-} or @samp{-T -}), then the file
+names are read from standard input.
+
+Unless you are running @command{tar} with @samp{--create}, you can not use
+both @samp{--files-from=-} and @samp{--file=-} (@samp{-f -}) in the same
+command.
+
+@FIXME{add bob's example, from his message on 2-10-97}
+
+The following example shows how to use @command{find} to generate a list of
+files smaller than 400K in length and put that list into a file
+called @file{small-files}. You can then use the @samp{-T} option to
+@command{tar} to specify the files from that file, @file{small-files}, to
+create the archive @file{little.tgz}. (The @samp{-z} option to
+@command{tar} compresses the archive with @command{gzip}; @pxref{gzip} for
+more information.)
+
+@example
+$ @kbd{find . -size -400 -print > small-files}
+$ @kbd{tar -c -v -z -T small-files -f little.tgz}
+@end example
+
+@noindent
+@FIXME{say more here to conclude the example/section?}
+
+@menu
+* nul::
+@end menu
+
+@node nul
+@subsection @kbd{NUL} Terminated File Names
+
+@cindex File names, terminated by @kbd{NUL}
+@cindex @kbd{NUL} terminated file names
+The @value{op-null} option causes @value{op-files-from} to read file
+names terminated by a @code{NUL} instead of a newline, so files whose
+names contain newlines can be archived using @samp{--files-from}.
+
+@table @kbd
+@item --null
+Only consider @kbd{NUL} terminated file names, instead of files that
+terminate in a newline.
+@end table
+
+The @samp{--null} option is just like the one in @acronym{GNU}
+@command{xargs} and @command{cpio}, and is useful with the
+@samp{-print0} predicate of @acronym{GNU} @command{find}. In
+@command{tar}, @samp{--null} also causes @value{op-directory} options
+to be treated as file names to archive, in case there are any files
+out there called @file{-C}.
+
+This example shows how to use @command{find} to generate a list of files
+larger than 800K in length and put that list into a file called
+@file{long-files}. The @samp{-print0} option to @command{find} just just
+like @samp{-print}, except that it separates files with a @kbd{NUL}
+rather than with a newline. You can then run @command{tar} with both the
+@samp{--null} and @samp{-T} options to specify that @command{tar} get the
+files from that file, @file{long-files}, to create the archive
+@file{big.tgz}. The @samp{--null} option to @command{tar} will cause
+@command{tar} to recognize the @kbd{NUL} separator between files.
+
+@example
+$ @kbd{find . -size +800 -print0 > long-files}
+$ @kbd{tar -c -v --null --files-from=long-files --file=big.tar}
+@end example
+
+@FIXME{say anything else here to conclude the section?}
+
+@node exclude
+@section Excluding Some Files
+@cindex File names, excluding files by
+@cindex Excluding files by name and pattern
+@cindex Excluding files by file system
+@UNREVISED
+
+To avoid operating on files whose names match a particular pattern,
+use the @value{op-exclude} or @value{op-exclude-from} options.
+
+@table @kbd
+@item --exclude=@var{pattern}
+Causes @command{tar} to ignore files that match the @var{pattern}.
+@end table
+
+@findex exclude
+The @value{op-exclude} option prevents any file or member whose name
+matches the shell wildcard (@var{pattern}) from being operated on.
+For example, to create an archive with all the contents of the directory
+@file{src} except for files whose names end in @file{.o}, use the
+command @samp{tar -cf src.tar --exclude='*.o' src}.
+
+You may give multiple @samp{--exclude} options.
+
+@table @kbd
+@item --exclude-from=@var{file}
+@itemx -X @var{file}
+Causes @command{tar} to ignore files that match the patterns listed in
+@var{file}.
+@end table
+
+@findex exclude-from
+Use the @samp{--exclude-from=@var{file-of-patterns}} option to read a
+list of patterns, one per line, from @var{file}; @command{tar} will
+ignore files matching those patterns. Thus if @command{tar} is
+called as @w{@samp{tar -c -X foo .}} and the file @file{foo} contains a
+single line @file{*.o}, no files whose names end in @file{.o} will be
+added to the archive.
+
+@FIXME{do the exclude options files need to have stuff separated by
+newlines the same as the files-from option does?}
+
+@menu
+* controlling pattern-patching with exclude::
+* problems with exclude::
+@end menu
+
+@node controlling pattern-patching with exclude
+@unnumberedsubsec Controlling Pattern-Matching with the @code{exclude} Options
+
+Normally, a pattern matches a name if an initial subsequence of the
+name's components matches the pattern, where @samp{*}, @samp{?}, and
+@samp{[...]} are the usual shell wildcards, @samp{\} escapes wildcards,
+and wildcards can match @samp{/}.
+
+Other than optionally stripping leading @samp{/} from names
+(@pxref{absolute}), patterns and names are used as-is. For
+example, trailing @samp{/} is not trimmed from a user-specified name
+before deciding whether to exclude it.
+
+However, this matching procedure can be altered by the options listed
+below. These options accumulate. For example:
+
+@example
+--ignore-case --exclude='makefile' --no-ignore-case ---exclude='readme'
+@end example
+
+ignores case when excluding @samp{makefile}, but not when excluding
+@samp{readme}.
+
+@table @option
+@item --anchored
+@itemx --no-anchored
+If anchored (the default), a pattern must match an initial subsequence
+of the name's components. Otherwise, the pattern can match any subsequence.
+
+@item --ignore-case
+@itemx --no-ignore-case
+When ignoring case, upper-case patterns match lower-case names and vice versa.
+When not ignoring case (the default), matching is case-sensitive.
+
+@item --wildcards
+@itemx --no-wildcards
+When using wildcards (the default), @samp{*}, @samp{?}, and @samp{[...]}
+are the usual shell wildcards, and @samp{\} escapes wildcards.
+Otherwise, none of these characters are special, and patterns must match
+names literally.
+
+@item --wildcards-match-slash
+@itemx --no-wildcards-match-slash
+When wildcards match slash (the default), a wildcard like @samp{*} in
+the pattern can match a @samp{/} in the name. Otherwise, @samp{/} is
+matched only by @samp{/}.
+
+@end table
+
+The @option{--recursion} and @option{--no-recursion} options
+(@pxref{recurse}) also affect how exclude patterns are interpreted. If
+recursion is in effect, a pattern excludes a name if it matches any of
+the name's parent directories.
+
+@node problems with exclude
+@unnumberedsubsec Problems with Using the @code{exclude} Options
+
+Some users find @samp{exclude} options confusing. Here are some common
+pitfalls:
+
+@itemize @bullet
+@item
+The main operating mode of @command{tar} does not act on a path name
+explicitly listed on the command line if one of its file name
+components is excluded. In the example above, if
+you create an archive and exclude files that end with @samp{*.o}, but
+explicitly name the file @samp{dir.o/foo} after all the options have been
+listed, @samp{dir.o/foo} will be excluded from the archive.
+
+@item
+You can sometimes confuse the meanings of @value{op-exclude} and
+@value{op-exclude-from}. Be careful: use @value{op-exclude} when files
+to be excluded are given as a pattern on the command line. Use
+@samp{--exclude-from=@var{file-of-patterns}} to introduce the name of a
+file which contains a list of patterns, one per line; each of these
+patterns can exclude zero, one, or many files.
+
+@item
+When you use @value{op-exclude}, be sure to quote the @var{pattern}
+parameter, so @acronym{GNU} @command{tar} sees wildcard characters
+like @samp{*}. If you do not do this, the shell might expand the
+@samp{*} itself using files at hand, so @command{tar} might receive a
+list of files instead of one pattern, or none at all, making the
+command somewhat illegal. This might not correspond to what you want.
+
+For example, write:
+
+@example
+$ @kbd{tar -c -f @var{archive.tar} --exclude '*.o' @var{directory}}
+@end example
+
+@noindent
+rather than:
+
+@example
+$ @kbd{tar -c -f @var{archive.tar} --exclude *.o @var{directory}}
+@end example
+
+@item
+You must use use shell syntax, or globbing, rather than @code{regexp}
+syntax, when using exclude options in @command{tar}. If you try to use
+@code{regexp} syntax to describe files to be excluded, your command
+might fail.
+
+@item
+In earlier versions of @command{tar}, what is now the
+@samp{--exclude-from=@var{file-of-patterns}} option was called
+@samp{--exclude=@var{pattern}} instead. Now,
+@samp{--exclude=@var{pattern}} applies to patterns listed on the command
+line and @samp{--exclude-from=@var{file-of-patterns}} applies to
+patterns listed in a file.
+
+@end itemize
+
+@node Wildcards
+@section Wildcards Patterns and Matching
+
+@dfn{Globbing} is the operation by which @dfn{wildcard} characters,
+@samp{*} or @samp{?} for example, are replaced and expanded into all
+existing files matching the given pattern. However, @command{tar} often
+uses wildcard patterns for matching (or globbing) archive members instead
+of actual files in the filesystem. Wildcard patterns are also used for
+verifying volume labels of @command{tar} archives. This section has the
+purpose of explaining wildcard syntax for @command{tar}.
+
+@FIXME{the next few paragraphs need work.}
+
+A @var{pattern} should be written according to shell syntax, using wildcard
+characters to effect globbing. Most characters in the pattern stand
+for themselves in the matched string, and case is significant: @samp{a}
+will match only @samp{a}, and not @samp{A}. The character @samp{?} in the
+pattern matches any single character in the matched string. The character
+@samp{*} in the pattern matches zero, one, or more single characters in
+the matched string. The character @samp{\} says to take the following
+character of the pattern @emph{literally}; it is useful when one needs to
+match the @samp{?}, @samp{*}, @samp{[} or @samp{\} characters, themselves.
+
+The character @samp{[}, up to the matching @samp{]}, introduces a character
+class. A @dfn{character class} is a list of acceptable characters
+for the next single character of the matched string. For example,
+@samp{[abcde]} would match any of the first five letters of the alphabet.
+Note that within a character class, all of the ``special characters''
+listed above other than @samp{\} lose their special meaning; for example,
+@samp{[-\\[*?]]} would match any of the characters, @samp{-}, @samp{\},
+@samp{[}, @samp{*}, @samp{?}, or @samp{]}. (Due to parsing constraints,
+the characters @samp{-} and @samp{]} must either come @emph{first} or
+@emph{last} in a character class.)
+
+@cindex Excluding characters from a character class
+@cindex Character class, excluding characters from
+If the first character of the class after the opening @samp{[}
+is @samp{!} or @samp{^}, then the meaning of the class is reversed.
+Rather than listing character to match, it lists those characters which
+are @emph{forbidden} as the next single character of the matched string.
+
+Other characters of the class stand for themselves. The special
+construction @samp{[@var{a}-@var{e}]}, using an hyphen between two
+letters, is meant to represent all characters between @var{a} and
+@var{e}, inclusive.
+
+@FIXME{need to add a sentence or so here to make this clear for those
+who don't have dan around.}
+
+Periods (@samp{.}) or forward slashes (@samp{/}) are not considered
+special for wildcard matches. However, if a pattern completely matches
+a directory prefix of a matched string, then it matches the full matched
+string: excluding a directory also excludes all the files beneath it.
+
+@node after
+@section Operating Only on New Files
+@cindex Excluding file by age
+@cindex Modification time, excluding files by
+@cindex Age, excluding files by
+@UNREVISED
+
+The @value{op-after-date} option causes @command{tar} to only work on files
+whose modification or inode-changed 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 last-modified 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 @samp{--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 actual contents of the file (rather than inode
+changes), then use the @value{op-newer-mtime} option.
+
+You may use these options with any operation. Note that these options
+differ from the @value{op-update} 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 @kbd
+@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 modification or inode-changed 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 last-modified time of that file is used as the date.
+
+@item --newer-mtime=@var{date}
+Acts like @value{op-after-date}, but only looks at modification times.
+@end table
+
+These options limit @command{tar} to only operating on files which have
+been modified after the date specified. A file is considered to have
+changed if the contents have been modified, or if the 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 @value{op-after-date} tests both the @code{mtime}
+(time the contents of the file were last modified) and @code{ctime}
+(time the file's status was last changed: owner, permissions, etc)
+fields, while @value{op-newer-mtime} tests only @code{mtime} field.
+
+To be precise, @value{op-after-date} checks @emph{both} @code{mtime} and
+@code{ctime} and processes the file if either one is more recent than
+@var{date}, while @value{op-newer-mtime} only checks @code{mtime} and
+disregards @code{ctime}. Neither uses @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.
+
+@FIXME{Need example of --newer-mtime with quoted argument.}
+
+@quotation
+@strong{Please Note:} @value{op-after-date} and @value{op-newer-mtime}
+should not be used for incremental backups. Some files (such as those
+in renamed directories) are not selected properly by these options.
+@xref{incremental and listed-incremental}.
+@end quotation
+
+@noindent
+@FIXME{which tells -- need to fill this in!}
+
+@node recurse
+@section Descending into Directories
+@cindex Avoiding recursion in directories
+@cindex Descending directories, avoiding
+@cindex Directories, avoiding recursion
+@cindex Recursion in directories, avoiding
+@UNREVISED
+
+@FIXME{arrggh! this is still somewhat confusing to me. :-< }
+
+@FIXME{show dan bob's comments, from 2-10-97}
+
+Usually, @command{tar} will recursively explore all directories (either
+those given on the command line or through the @value{op-files-from}
+option) for the various files they contain. However, you may not always
+want @command{tar} to act this way.
+
+The @value{op-no-recursion} option inhibits @command{tar}'s recursive descent
+into specified directories. If you specify @samp{--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 @kbd
+@item --no-recursion
+Prevents @command{tar} from recursively descending directories.
+
+@item --recursion
+Requires @command{tar} to recursively descend directories.
+This is the default.
+@end table
+
+When you use @samp{--no-recursion}, @acronym{GNU} @command{tar} 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{! -d}} option
+to @command{find} @FIXME{needs more explanation or a cite to another
+info file}as they usually do not want all the files in a directory.
+They then use the @value{op-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
+@value{op-same-permissions} option does not affect them---while users
+might really like it to. Specifying @value{op-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.
+
+The @value{op-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 @value{op-no-recursion} option also affects how exclude patterns
+are interpreted (@pxref{controlling pattern-patching with exclude}).
+
+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:
+
+@example
+$ @kbd{tar -cf jams.tar --norecursion grape --recursion grape/concord}
+@end example
+
+@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 Filesystem 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
+@value{op-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 @value{op-files-from}, regardless of where they reside.
+
+@table @kbd
+@item --one-file-system
+@itemx -l
+Prevents @command{tar} from crossing file system boundaries when
+archiving. Use in conjunction with any write operation.
+@end table
+
+The @samp{--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 filesystem 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.
+
+It is reported that using this option, the mount point is is archived,
+but nothing under it.
+
+This option is useful for making full or incremental archival backups of
+a file system. If this option is used in conjunction with
+@value{op-verbose}, 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
+@UNREVISED
+
+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
+@value{op-files-from}, use @value{op-directory}. This will change the
+working directory to the directory @var{directory} after that point in
+the list.
+
+@table @kbd
+@item --directory=@var{directory}
+@itemx -C @var{directory}
+Changes the working directory in the middle of a command line.
+@end table
+
+For example,
+
+@example
+$ @kbd{tar -c -f jams.tar grape prune -C food cherry}
+@end example
+
+@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,
+
+@example
+$ @kbd{tar -c -f jams.tar grape prune -C food red/cherry}
+@end example
+
+@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 @samp{--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}:
+
+@example
+$ @kbd{tar -c -f foo.tar -C /etc passwd hosts -C /lib libc.a}
+@end example
+
+@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 @samp{--directory} options are interpreted consecutively. If
+@samp{--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
+@samp{--directory} option.
+
+@FIXME{dan: does this mean that you *can* use the short option form, but
+you can *not* use the long option form with --files-from? or is this
+totally screwed?}
+
+When using @samp{--files-from} (@pxref{files}), you can put @samp{-C}
+options in the file list. Unfortunately, you cannot put
+@samp{--directory} options in the file list. (This interpretation can
+be disabled by using the @value{op-null} option.)
+
+@node absolute
+@subsection Absolute File Names
+@UNREVISED
+
+@table @kbd
+@item -P
+@itemx --absolute-names
+Do not strip leading slashes from file names, and permit file names
+containing a @file{..} file name component.
+@end table
+
+By default, @acronym{GNU} @command{tar} 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-@acronym{GNU} @command{tar}
+program to use. Therefore, @acronym{GNU} @command{tar} 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}.
+
+If you use the @value{op-absolute-names} option, @command{tar} will do
+none of these transformations.
+
+To archive or extract files relative to the root directory, specify
+the @value{op-absolute-names} 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 @value{op-absolute-names}, @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 @value{op-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 @kbd
+@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 @acronym{GNU} @command{tar}
+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}:
+
+@example
+$ @kbd{tar -c -f archive.tar /home 2> /dev/null}
+@end example
+
+@noindent
+Another solution, both nicer and simpler, would be to change to
+the @file{/} directory first, and then avoid absolute notation.
+For example:
+
+@example
+$ @kbd{(cd / && tar -c -f archive.tar home)}
+$ @kbd{tar -c -f archive.tar -C / home}
+@end example
+
+@include getdate.texi
+
+@node Formats
+@chapter Controlling the Archive Format
+
+@FIXME{need an intro here}
+
+@menu
+* Portability:: Making @command{tar} Archives More Portable
+* Compression:: Using Less Space through Compression
+* Attributes:: Handling File Attributes
+* Standard:: The Standard Format
+* Extensions:: @acronym{GNU} Extensions to the Archive Format
+* cpio:: Comparison of @command{tar} and @command{cpio}
+@end menu
+
+@node Portability
+@section Making @command{tar} Archives More Portable
+
+Creating a @command{tar} archive on a particular system that is meant to be
+useful later on many other machines and with other versions of @command{tar}
+is more challenging than you might think. @command{tar} archive formats
+have been evolving since the first versions of Unix. Many such formats
+are around, and are not always compatible with each other. This section
+discusses a few problems, and gives some advice about making @command{tar}
+archives more portable.
+
+One golden rule is simplicity. For example, limit your @command{tar}
+archives to contain only regular files and directories, avoiding
+other kind of special files. Do not attempt to save sparse files or
+contiguous files as such. Let's discuss a few more problems, in turn.
+
+@menu
+* Portable Names:: Portable Names
+* dereference:: Symbolic Links
+* old:: Old V7 Archives
+* posix:: @sc{posix} archives
+* Checksumming:: Checksumming Problems
+* Large or Negative Values:: Large files, negative time stamps, etc.
+@end menu
+
+@node Portable Names
+@subsection Portable Names
+
+Use portable file and member names. A name is portable if it contains
+only ASCII letters and digits, @samp{/}, @samp{.}, @samp{_}, and
+@samp{-}; it cannot be empty, start with @samp{-} or @samp{//}, or
+contain @samp{/-}. Avoid deep directory nesting. For portability to
+old Unix hosts, limit your file name components to 14 characters or
+less.
+
+If you intend to have your @command{tar} archives to be read under
+MSDOS, you should not rely on case distinction for file names, and you
+might use the @acronym{GNU} @command{doschk} program for helping you
+further diagnosing illegal MSDOS names, which are even more limited
+than System V's.
+
+@node dereference
+@subsection Symbolic Links
+@cindex File names, using symbolic links
+@cindex Symbolic link as file name
+
+Normally, when @command{tar} archives a symbolic link, it writes a
+block to the archive naming the target of the link. In that way, the
+@command{tar} archive is a faithful record of the filesystem contents.
+@value{op-dereference} is used with @value{op-create}, and causes
+@command{tar} to archive the files symbolic links point to, instead of
+the links themselves. When this option is used, when @command{tar}
+encounters a symbolic link, it will archive the linked-to file,
+instead of simply recording the presence of a symbolic link.
+
+The name under which the file is stored in the file system is not
+recorded in the archive. To record both the symbolic link name and
+the file name in the system, archive the file under both names. If
+all links were recorded automatically by @command{tar}, an extracted file
+might be linked to a file name that no longer exists in the file
+system.
+
+If a linked-to file is encountered again by @command{tar} while creating
+the same archive, an entire second copy of it will be stored. (This
+@emph{might} be considered a bug.)
+
+So, for portable archives, do not archive symbolic links as such,
+and use @value{op-dereference}: many systems do not support
+symbolic links, and moreover, your distribution might be unusable if
+it contains unresolved symbolic links.
+
+@node old
+@subsection Old V7 Archives
+@cindex Format, old style
+@cindex Old style format
+@cindex Old style archives
+
+Certain old versions of @command{tar} cannot handle additional
+information recorded by newer @command{tar} programs. To create an
+archive in V7 format (not ANSI), which can be read by these old
+versions, specify the @value{op-old-archive} option in
+conjunction with the @value{op-create}. @command{tar} also
+accepts @samp{--portability} for this option. When you specify it,
+@command{tar} leaves out information about directories, pipes, fifos,
+contiguous files, and device files, and specifies file ownership by
+group and user IDs instead of group and user names.
+
+When updating an archive, do not use @value{op-old-archive}
+unless the archive was created with using this option.
+
+In most cases, a @emph{new} format archive can be read by an @emph{old}
+@command{tar} program without serious trouble, so this option should
+seldom be needed. On the other hand, most modern @command{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
+@subsection @acronym{GNU} @command{tar} and @sc{posix} @command{tar}
+
+@acronym{GNU} @command{tar} was based on an early draft of the
+@sc{posix} 1003.1 @code{ustar} standard. @acronym{GNU} extensions to
+@command{tar}, such as the support for file names longer than 100
+characters, use portions of the @command{tar} header record which were
+specified in that @sc{posix} draft as unused. Subsequent changes in
+@sc{posix} have allocated the same parts of the header record for
+other purposes. As a result, @acronym{GNU} @command{tar} is
+incompatible with the current @sc{posix} spec, and with @command{tar}
+programs that follow it.
+
+We plan to reimplement these @acronym{GNU} extensions in a new way which is
+upward compatible with the latest @sc{posix} @command{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 @acronym{GNU} @command{tar} archive, which uses the
+@acronym{GNU} extensions, using some other @command{tar} program. So
+if you want to read the archive with another @command{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 @command{tar}s have a limit of 100 characters.
+@acronym{GNU} @command{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, @acronym{GNU} @command{tar} should be able to handle file
+names of practically unlimited length. So, if @acronym{GNU}
+@command{tar} fails to dump and retrieve files having more than 100
+characters, then there is a bug in @acronym{GNU} @command{tar},
+indeed.
+
+But, being strictly @sc{posix}, the limit was still 100 characters.
+For various other purposes, @acronym{GNU} @command{tar} used areas
+left unassigned in the @sc{posix} draft. @sc{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 @sc{posix} limit
+oscillates between 100 and 256, depending on the precise location of
+slashes in full file name (this is rather ugly). Since @acronym{GNU}
+@command{tar} use the same fields for quite other purposes, it became
+incompatible with the latest @sc{posix} standards.
+
+For longer or non-fitting file names, we plan to use yet another set
+of @acronym{GNU} extensions, but this time, complying with the
+provisions @sc{posix} offers for extending the format, rather than
+conflicting with it. Whenever an archive uses old @acronym{GNU}
+@command{tar} extension format or @sc{posix} extensions, would it be
+for very long file names or other specialities, this archive becomes
+non-portable to other @command{tar} implementations. In fact,
+anything can happen. The most forgiving @command{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.
+@command{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.
+@acronym{GNU} @command{tar} should be able to produce and read true
+@sc{posix} format files, while being able to detect old @acronym{GNU}
+@command{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
+@sc{posix} conforming archives. Past 256, I do not know yet if
+@acronym{GNU} @command{tar} will go non-@sc{posix} again, or merely
+refuse to archive the file.
+
+There are plans so @acronym{GNU} @command{tar} support more fully the
+latest @sc{posix} format, while being able to read old V7 format,
+@acronym{GNU} (semi-@sc{posix} plus extension), as well as full
+@sc{posix}. One may ask if there is part of the @sc{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 @sc{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.
+
+@sc{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
+@env{POSIXLY_CORRECT} is set), I suspect that @acronym{GNU}
+@command{tar} should disobey this specification, and automatically
+switch to using @acronym{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 @sc{posix} archive with names having more than 100
+characters, I guess that @acronym{GNU} @command{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 @acronym{GNU} @command{tar} should produce
+@sc{posix} format by default, whenever possible, producing archives
+older versions of @acronym{GNU} @command{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 @acronym{GNU} @command{tar} to go closer to
+@sc{posix}. We can rush it. Another possibility is to produce the
+current @acronym{GNU} @command{tar} format by default for a few years,
+but have @acronym{GNU} @command{tar} versions from some 1.@var{POSIX}
+and up able to recognize all three formats, and let older
+@acronym{GNU} @command{tar} fade out slowly. Then, we could switch to
+producing @sc{posix} format by default, with not much harm to those
+still having (very old at that time) @acronym{GNU} @command{tar}
+versions prior to 1.@var{POSIX}.
+
+@sc{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
+@env{POSIXLY_CORRECT}. Otherwise, if @command{tar} is given long
+names, or @samp{-[VMSgG]}, then it should automatically go non-@sc{posix}.
+I think this is easily granted without much discussion.
+
+Another point is that only @code{mtime} is stored in @sc{posix}
+archives, while @acronym{GNU} @command{tar} currently also store
+@code{atime} and @code{ctime}. If we want @acronym{GNU} @command{tar}
+to go closer to @sc{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, @sc{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 @acronym{GNU} @command{tar} to go closer to @sc{posix} on
+average, while producing files. My choice would be to go closer to
+@sc{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 @sc{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 @acronym{GNU}-format archives, and recover its
+previous meaning from this fact.
+
+@acronym{GNU}-format as it exists now can easily fool other @sc{posix}
+@command{tar}, as it uses fields which @sc{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 @acronym{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 @sc{posix} header
+block. I could manage to do that portably between future
+@acronym{GNU} @command{tar}s. So other @sc{posix} @command{tar}s
+might be at least able to provide kind of correct listings for the
+archives produced by @acronym{GNU} @command{tar}, if not able to
+process them otherwise.
+
+Using these projected extensions might induce older @command{tar}s to
+fail. We would use the same approach as for @sc{posix}. I'll put out
+a @command{tar} capable of reading @sc{posix}ier, yet extended
+archives, but will not produce this format by default, in
+@acronym{GNU} mode. In a few years, when newer @acronym{GNU}
+@command{tar}s will have flooded out @command{tar} 1.11.X and
+previous, we could switch to producing @sc{posix}ier extended
+archives, with no real harm to users, as almost all existing
+@acronym{GNU} @command{tar}s will be ready to read @sc{posix}ier
+format. In fact, I'll do both changes at the same time, in a few
+years, and just prepare @command{tar} for both changes, without
+effecting them, from 1.@var{POSIX}. (Both changes: 1---using
+@sc{posix} convention for getting over 100 characters; 2---avoiding
+mangling @sc{posix} headers for @acronym{GNU} extensions, using only
+@sc{posix} mandated extension techniques).
+
+So, a future @command{tar} will have a @value{op-posix} flag forcing
+the usage of truly @sc{posix} headers, and so, producing archives
+previous @acronym{GNU} @command{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 @acronym{GNU} @command{tar} with @value{op-posix} and other
+@sc{posix} @command{tar}.
+
+In a few years, when @acronym{GNU} @command{tar} will produce
+@sc{posix} headers by default, @value{op-posix} will have a strong
+meaning and will disallow @acronym{GNU} extensions. But in the
+meantime, for a long while, @value{op-posix} in @acronym{GNU} tar will
+not disallow @acronym{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 @acronym{GNU} extensions will
+use @sc{posix} headers with reserved-for-users extensions to headers,
+and I will be curious to know how well or bad @sc{posix}
+@command{tar}s will react to these.
+
+@acronym{GNU} @command{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 @acronym{GNU} @command{tar} not to recognize @sc{posix}
+archives, and consequently, wrongly decide those archives are in old
+V7 format. It is a useful bug for me, because @acronym{GNU}
+@command{tar} has other @sc{posix} incompatibilities, and I need to
+segregate @acronym{GNU} @command{tar} semi-@sc{posix} archives from
+truly @sc{posix} archives, for @acronym{GNU} @command{tar} should be
+somewhat compatible with itself, while migrating closer to latest
+@sc{posix} standards. So, I'll be very careful about how and when I
+will do the correction.
+
+@node Checksumming
+@subsection Checksumming Problems
+
+SunOS and HP-UX @command{tar} fail to accept archives created using
+@acronym{GNU} @command{tar} and containing non-ASCII file names, that
+is, file names having characters with the eight bit set, because they
+use signed checksums, while @acronym{GNU} @command{tar} uses unsigned
+checksums while creating archives, as per @sc{posix} standards. On
+reading, @acronym{GNU} @command{tar} computes both checksums and
+accept any. It is somewhat worrying that a lot of people may go
+around doing backup of their files using faulty (or at least
+non-standard) software, not learning about it until it's time to
+restore their missing files with an incompatible file extractor, or
+vice versa.
+
+@acronym{GNU} @command{tar} compute checksums both ways, and accept
+any on read, so @acronym{GNU} tar can read Sun tapes even with their
+wrong checksums. @acronym{GNU} @command{tar} produces the standard
+checksum, however, raising incompatibilities with Sun. That is to
+say, @acronym{GNU} @command{tar} has not been modified to
+@emph{produce} incorrect archives to be read by buggy @command{tar}'s.
+I've been told that more recent Sun @command{tar} now read standard
+archives, so maybe Sun did a similar patch, after all?
+
+The story seems to be that when Sun first imported @command{tar}
+sources on their system, they recompiled it without realizing that
+the checksums were computed differently, because of a change in
+the default signing of @code{char}'s in their compiler. So they
+started computing checksums wrongly. When they later realized their
+mistake, they merely decided to stay compatible with it, and with
+themselves afterwards. Presumably, but I do not really know, HP-UX
+has chosen that their @command{tar} archives to be compatible with Sun's.
+The current standards do not favor Sun @command{tar} format. In any
+case, it now falls on the shoulders of SunOS and HP-UX users to get
+a @command{tar} able to read the good archives they receive.
+
+@node Large or Negative Values
+@subsection Large or Negative Values
+@cindex large values
+@cindex future time stamps
+@cindex negative time stamps
+
+@sc{posix} @command{tar} format uses fixed-sized unsigned octal strings
+to represent numeric values. User and group IDs and device major and
+minor numbers have unsigned 21-bit representations, and file sizes and
+times have unsigned 33-bit representations. @acronym{GNU} @command{tar}
+generates @sc{posix} representations when possible, but for values
+outside the @sc{posix} range it generates two's-complement base-256
+strings: uids, gids, and device numbers have signed 57-bit
+representations, and file sizes and times have signed 89-bit
+representations. These representations are an extension to @sc{posix}
+@command{tar} format, so they are not universally portable.
+
+The most common portability problems with out-of-range numeric values
+are large files and future or negative time stamps.
+
+Portable archives should avoid members of 8 GB or larger, as @sc{posix}
+@command{tar} format cannot represent them.
+
+Portable archives should avoid time stamps from the future. @sc{posix}
+@command{tar} format can represent time stamps in the range 1970-01-01
+00:00:00 through 2242-03-16 12:56:31 @sc{utc}. However, many current
+hosts use a signed 32-bit @code{time_t}, or internal time stamp format,
+and cannot represent time stamps after 2038-01-19 03:14:07 @sc{utc}; so
+portable archives must avoid these time stamps for many years to come.
+
+Portable archives should also avoid time stamps before 1970. These time
+stamps are a common @sc{posix} extension but their @code{time_t}
+representations are negative. Many traditional @command{tar}
+implementations generate a two's complement representation for negative
+time stamps that assumes a signed 32-bit @code{time_t}; hence they
+generate archives that are not portable to hosts with differing
+@code{time_t} representations. @acronym{GNU} @command{tar} recognizes this
+situation when it is run on host with a signed 32-bit @code{time_t}, but
+it issues a warning, as these time stamps are nonstandard and unportable.
+
+@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
+@UNREVISED
+
+@table @kbd
+@item -z
+@itemx --gzip
+@itemx --ungzip
+Filter the archive through @command{gzip}.
+@end table
+
+@FIXME{ach; these two bits orig from "compare" (?). where to put?} Some
+format parameters must be taken into consideration when modifying an
+archive.@FIXME{???} Compressed archives cannot be modified.
+
+You can use @samp{--gzip} and @samp{--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 @command{tar} program to enforce the specified (or default) record
+size. The default compression parameters are used; if you need to
+override them, avoid the @value{op-gzip} option and run @command{gzip}
+explicitly. (Or set the @env{GZIP} environment variable.)
+
+The @value{op-gzip} option does not work with the @value{op-multi-volume}
+option, or with the @value{op-update}, @value{op-append},
+@value{op-concatenate}, or @value{op-delete} operations.
+
+It is not exact to say that @acronym{GNU} @command{tar} is to work in concert
+with @command{gzip} in a way similar to @command{zip}, say. Surely, it is
+possible that @command{tar} and @command{gzip} be done with a single call,
+like in:
+
+@example
+$ @kbd{tar cfz archive.tar.gz subdir}
+@end example
+
+@noindent
+to save all of @samp{subdir} into a @code{gzip}'ed archive. Later you
+can do:
+
+@example
+$ @kbd{tar xfz archive.tar.gz}
+@end example
+
+@noindent
+to explode and unpack.
+
+The difference is that the whole archive is compressed. With
+@command{zip}, archive members are archived individually. @command{tar}'s
+method yields better compression. On the other hand, one can view the
+contents of a @command{zip} archive without having to decompress it. As
+for the @command{tar} and @command{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:
+
+@example
+$ @kbd{tar tfz archive.tar.gz}
+@end example
+
+@cindex corrupted archives
+About corrupted compressed archives: @command{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 unsynchronized, 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 @acronym{GNU} @command{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
+lose some compressibility. But this would have make recovering easier.
+So, there are pros and cons. We'll see!
+
+@table @kbd
+@item -j
+@itemx --bzip2
+Filter the archive through @code{bzip2}. Otherwise like @value{op-gzip}.
+
+@item -Z
+@itemx --compress
+@itemx --uncompress
+Filter the archive through @command{compress}. Otherwise like
+@value{op-gzip}.
+
+@item --use-compress-program=@var{prog}
+Filter through @var{prog} (must accept @samp{-d}).
+@end table
+
+@value{op-compress} 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. @value{op-compress} causes
+@command{tar} to compress when writing the archive, or to uncompress when
+reading the archive.
+
+To perform compression and uncompression on the archive, @command{tar}
+runs the @command{compress} utility. @command{tar} uses the default
+compression parameters; if you need to override them, avoid the
+@value{op-compress} option and run the @command{compress} utility
+explicitly. It is useful to be able to call the @command{compress}
+utility from within @command{tar} because the @command{compress} utility by
+itself cannot access remote tape drives.
+
+The @value{op-compress} option will not work in conjunction with the
+@value{op-multi-volume} option or the @value{op-append}, @value{op-update}
+and @value{op-delete} operations. @xref{Operations}, for
+more information on these operations.
+
+If there is no compress utility available, @command{tar} will report an error.
+@strong{Please note} that the @command{compress} program may be covered by
+a patent, and therefore we recommend you stop using it.
+
+@value{op-bzip2} acts like @value{op-compress}, except that it uses
+the @code{bzip2} utility.
+
+@table @kbd
+@item --compress
+@itemx --uncompress
+@itemx -z
+@itemx -Z
+When this option is specified, @command{tar} will compress (when
+writing an archive), or uncompress (when reading an archive). Used in
+conjunction with the @value{op-create}, @value{op-extract},
+@value{op-list} and @value{op-compare} operations.
+@end table
+
+You can have archives be compressed by using the @value{op-gzip} option.
+This will arrange for @command{tar} to use the @command{gzip} program to be
+used to compress or uncompress the archive wren writing or reading it.
+
+To use the older, obsolete, @command{compress} program, use the
+@value{op-compress} option. The @acronym{GNU} Project recommends you not use
+@command{compress}, because there is a patent covering the algorithm it
+uses. You could be sued for patent infringement merely by running
+@command{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 @value{op-gzip}, but I'd also like
+the output to be fed through a program like @acronym{GNU}
+@command{ecc} (actually, right now that's @samp{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 @command{tar} through @command{ecc}, but then I lose (though I
+haven't started using it yet, I confess) the ability to have
+@command{tar} use @command{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 operations, 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 @command{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 (apparently) working, do you accept contributed changes to
+utilities like that? (Leigh Clayton @file{loc@@soliton.com}, May 1995).
+
+Isn't that exactly the role of the @value{op-use-compress-prog} option?
+I never tried it myself, but I suspect you may want to write a
+@var{prog} script or program able to filter stdin to stdout to
+way you want. It should recognize the @samp{-d} option, for when
+extraction is needed rather than creation.
+
+It has been reported that if one writes compressed data (through the
+@value{op-gzip} or @value{op-compress} 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.
+
+@node sparse
+@subsection Archiving Sparse Files
+@cindex Sparse Files
+@UNREVISED
+
+@table @kbd
+@item -S
+@itemx --sparse
+Handle sparse files efficiently.
+@end table
+
+This option causes all files to be put in the archive to be tested for
+sparseness, and handled specially if they are. The @value{op-sparse}
+option is useful when many @code{dbm} files, for example, are being
+backed up. Using this option dramatically decreases the amount of
+space needed to store such a file.
+
+In later versions, this option may be removed, and the testing and
+treatment of sparse files may be done automatically with any special
+@acronym{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 zeros. 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, @command{tar}
+could create an archive longer than the original. To have @command{tar}
+attempt to recognize the holes in a file, use @value{op-sparse}. When
+you use the @value{op-sparse} option, then, for any file using less
+disk space than would be expected from its length, @command{tar} searches
+the file for consecutive stretches of zeros. It then records in the
+archive for the file where the consecutive stretches of zeros are, and
+only archives the ``real contents'' of the file. On extraction (using
+@value{op-sparse} is not needed on extraction) any such files have
+hols created wherever the continuous stretches of zeros were found.
+Thus, if you use @value{op-sparse}, @command{tar} archives won't take
+more space than the original.
+
+A file is sparse if it contains blocks of zeros whose existence is
+recorded, but that have no space allocated on disk. When you specify
+the @value{op-sparse} option in conjunction with the @value{op-create}
+operation, @command{tar} tests all files for sparseness while archiving.
+If @command{tar} finds a file to be sparse, it uses a sparse representation of
+the file in the archive. @value{xref-create}, for more information
+about creating archives.
+
+@value{op-sparse} is useful when archiving files, such as dbm files,
+likely to contain many nulls. This option dramatically
+decreases the amount of space needed to store such an archive.
+
+@quotation
+@strong{Please Note:} Always use @value{op-sparse} 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 @value{op-sparse} 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). @FIXME-xref{incremental when node name is set.}
+@end quotation
+
+@command{tar} ignores the @value{op-sparse} option when reading an archive.
+
+@table @kbd
+@item --sparse
+@itemx -S
+Files stored sparsely in the file system are represented sparsely in
+the archive. Use in conjunction with write operations.
+@end table
+
+However, users should be well aware that at archive creation time,
+@acronym{GNU} @command{tar} still has to read whole disk file to
+locate the @dfn{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 @file{core} file of over 400 megabytes, but with only about
+3 megabytes of actual data, took about 9 minutes on a Sun Sparcstation
+ELC, with full CPU utilization.)
+
+This reading is required in all cases and is not related to the fact
+the @value{op-sparse} option is used or not, so by merely @emph{not}
+using the option, you are not saving time@footnote{Well! We should say
+the whole truth, here. When @value{op-sparse} is selected while creating
+an archive, the current @command{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.}.
+
+Programs like @command{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.
+@acronym{GNU} @command{tar} uses a more portable and straightforward
+archiving approach, it would be fairly difficult that it does
+otherwise. Elizabeth Zwicky writes to @file{comp.unix.internals}, on
+1990-12-10: