+@example
+$ @kbd{tar -tvf bluesrock.tar}
+-rw-rw-rw- melissa user 105 1997-01-21 19:42 blues
+-rw-rw-rw- melissa user 33 1997-01-20 15:34 rock
+$ @kbd{tar -tvf folkjazz.tar}
+-rw-rw-rw- melissa user 20 1996-09-23 16:44 folk
+-rw-rw-rw- melissa user 65 1997-01-30 14:15 jazz
+@end example
+
+We can concatenate these two archives with @code{tar}:
+
+@example
+$ @kbd{cd ..}
+$ @kbd{tar --concatenate --file=bluesrock.tar jazzfolk.tar}
+@end example
+
+If you now list the contents of the @file{bluesclass.tar}, you will see
+that now it also contains the archive members of @file{jazzfolk.tar}:
+
+@example
+$ @kbd{tar --list --file=bluesrock.tar}
+blues
+rock
+jazz
+folk
+@end example
+
+When you use @samp{--concatenate}, the source and target archives must
+already exist and must have been created using compatable format
+parameters (@FIXME-pxref{Matching Format Parameters}). The new,
+concatenated archive will be called by the same name as the first
+archive listed on the command line. @FIXME{is there a way to specify a
+new name?}
+
+Like @value{op-append}, this operation cannot be performed on some
+tape drives, due to deficiencies in the formats those tape drives use.
+
+@cindex @code{concatenate} vs @code{cat}
+@cindex @code{cat} vs @code{concatenate}
+It may seem more intuitive to you to want or try to use @code{cat} to
+concatenate two archives instead of using the @samp{--concatenate}
+operation; after all, @code{cat} is the utility for combining files.
+
+However, @code{tar} archives incorporate an end-of-file marker which
+must be removed if the concatenated archives are to be read properly as
+one archive. @samp{--concatenate} removes the end-of-archive marker
+from the target archive before each new archive is appended. If you use
+@code{cat} to combine the archives, the result will not be a valid
+@code{tar} format archive. If you need to retrieve files from an
+archive that was added to using the @code{cat} utility, use the
+@value{op-ignore-zeros} option. @xref{Ignore Zeros} for further
+information on dealing with archives improperly combined using the
+@code{cat} shell utility.
+
+@FIXME{this shouldn't go here. where should it go?} You must specify
+the source archives using @value{op-file} (@value{pxref-file}). If you
+do not specify the target archive, @code{tar} uses the value of the
+environment variable @code{TAPE}, or, if this has not been set, the
+default archive name.
+
+@node delete, compare, concatenate, Advanced tar
+@subsection Removing Archive Members Using @samp{--delete}
+@UNREVISED
+@cindex Deleting files from an archive
+@cindex Removing files from an archive
+
+You can remove members from an archive by using the @value{op-delete}
+option. Specify the name of the archive with @value{op-file} and then
+specify the names of the members to be deleted; if you list no member
+names, nothing will be deleted. The @value{op-verbose} option will
+cause @code{tar} to print the names of the members as they are deleted.
+As with @value{op-extract}, you must give the exact member names when
+using @samp{tar --delete}. @samp{--delete} will remove all versions of
+the named file from the archive. The @samp{--delete} operation can run
+very slowly.
+
+Unlike other operations, @samp{--delete} has no short form.
+
+@cindex Tapes, using @code{--delete} and
+@cindex Deleting from tape archives
+This operation will rewrite the archive. You can only use
+@samp{--delete} on an archive if the archive device allows you to
+write to any point on the media, such as a disk; because of this, it
+does not work on magnetic tapes. Do not try to delete an archive member
+from a magnetic tape; the action will not succeed, and you will be
+likely to scramble the archive and damage your tape. There is no safe
+way (except by completely re-writing the archive) to delete files from
+most kinds of magnetic tape. @xref{Media}.
+
+To delete all versions of the file @file{blues} from the archive
+@file{collection.tar} in the @file{practice} directory, make sure you
+are in that directory, and then,
+
+@example
+$ @kbd{tar --list --file=collection.tar}
+blues
+folk
+jazz
+rock
+practice/blues
+practice/folk
+practice/jazz
+practice/rock
+practice/blues
+$ @kbd{tar --delete --file=collection.tar blues}
+$ @kbd{tar --list --file=collection.tar}
+folk
+jazz
+rock
+$
+@end example
+
+@FIXME{I changed the order of these nodes around and haven't had a chance
+to fix the above example's results, yet. I have to play with this and
+follow it and see what it actually does!}
+
+The @value{op-delete} option has been reported to work properly when
+@code{tar} acts as a filter from @code{stdin} to @code{stdout}.
+
+@node compare, , delete, Advanced tar
+@subsection Comparing Archive Members with the File System
+@cindex Verifying the currency of an archive
+@UNREVISED
+
+The @samp{--compare} (@samp{-d}), or @samp{--diff} operation compares
+specified archive members against files with the same names, and then
+reports differences in file size, mode, owner, modification date and
+contents. You should @emph{only} specify archive member names, not file
+names. If you do not name any members, then @code{tar} will compare the
+entire archive. If a file is represented in the archive but does not
+exist in the file system, @code{tar} reports a difference.
+
+You have to specify the record size of the archive when modifying an
+archive with a non-default record size.
+
+@code{tar} ignores files in the file system that do not have
+corresponding members in the archive.
+
+The following example compares the archive members @file{rock},
+@file{blues} and @file{funk} in the archive @file{bluesrock.tar} with
+files of the same name in the file system. (Note that there is no file,
+@file{funk}; @code{tar} will report an error message.)
+
+@example
+$ @kbd{tar --compare --file=bluesrock.tar rock blues funk}
+rock
+blues
+tar: funk not found in archive
+@end example
+
+@noindent
+@FIXME{what does this actually depend on? i'm making a guess,
+here.}Depending on the system where you are running @code{tar} and the
+version you are running, @code{tar} may have a different error message,
+such as:
+
+@example
+funk: does not exist
+@end example
+
+@FIXME-xref{somewhere, for more information about format parameters.
+Melissa says: such as "format variations"? But why? Clearly I don't
+get it yet; I'll deal when I get to that section.}
+
+The spirit behind the @value{op-compare} option is to check whether the
+archive represents the current state of files on disk, more than validating
+the integrity of the archive media. For this later goal, @xref{verify}.
+
+@node extract options, backup, Advanced tar, operations
+@section Options Used by @code{--extract}
+@UNREVISED
+
+@FIXME{i need to get dan to go over these options with me and see if
+there's a better way of organizing them.}
+
+The previous chapter showed how to use @value{op-extract} to extract
+an archive into the filesystem. Various options cause @code{tar} to
+extract more information than just file contents, such as the owner,
+the permissions, the modification date, and so forth. This section
+presents options to be used with @samp{--extract} when certain special
+considerations arise. You may review the information presented in
+@ref{extract} for more basic information about the
+@samp{--extract} operation.
+
+@menu
+* Reading:: Options to Help Read Archives
+* Writing:: Changing How @code{tar} Writes Files
+* Scarce:: Coping with Scarce Resources
+@end menu
+
+@node Reading, Writing, extract options, extract options
+@subsection Options to Help Read Archives
+@cindex Options when reading archives
+@cindex Reading incomplete records
+@cindex Records, incomplete
+@cindex End-of-archive entries, ignoring
+@cindex Ignoring end-of-archive entries
+@cindex Large lists of file names on small machines
+@cindex Small memory
+@cindex Running out of space
+@UNREVISED
+
+Normally, @code{tar} will request data in full record increments from
+an archive storage device. If the device cannot return a full record,
+@code{tar} will report an error. However, some devices do not always
+return full records, or do not require the last record of an archive to
+be padded out to the next record boundary. To keep reading until you
+obtain a full record, or to accept an incomplete record if it contains
+an end-of-archive marker, specify the @value{op-read-full-records} option
+in conjunction with the @value{op-extract} or @value{op-list} operations.
+@value{xref-read-full-records}.
+
+The @value{op-read-full-records} option is turned on by default when
+@code{tar} reads an archive from standard input, or from a remote
+machine. This is because on BSD Unix systems, attempting to read a
+pipe returns however much happens to be in the pipe, even if it is
+less than was requested. If this option were not enabled, @code{tar}
+would fail as soon as it read an incomplete record from the pipe.
+
+If you're not sure of the blocking factor of an archive, you can
+read the archive by specifying @value{op-read-full-records} and
+@value{op-blocking-factor}, using a blocking factor larger than what the
+archive uses. This lets you avoid having to determine the blocking factor
+of an archive. @value{xref-blocking-factor}.
+
+@menu
+* read full records::
+* Ignore Zeros::
+* Ignore Failed Read::
+@end menu
+
+@node read full records, Ignore Zeros, Reading, Reading
+@unnumberedsubsubsec Reading Full Records
+
+@FIXME{need sentence or so of intro here}
+
+@table @kbd
+@item --read-full-records
+@item -B
+Use in conjunction with @value{op-extract} to read an archive which
+contains incomplete records, or one which has a blocking factor less
+than the one specified.
+@end table
+
+@node Ignore Zeros, Ignore Failed Read, read full records, Reading
+@unnumberedsubsubsec Ignoring Blocks of Zeros
+
+Normally, @code{tar} stops reading when it encounters a block of zeros
+between file entries (which usually indicates the end of the archive).
+@value{op-ignore-zeros} allows @code{tar} to completely read an archive
+which contains a block of zeros before the end (i.e.@: a damaged
+archive, or one which was created by @code{cat}-ing several archives
+together).
+
+The @value{op-ignore-zeros} option is turned off by default because many
+versions of @code{tar} write garbage after the end-of-archive entry,
+since that part of the media is never supposed to be read. GNU
+@code{tar} does not write after the end of an archive, but seeks to
+maintain compatablity among archiving utilities.
+
+@table @kbd
+@item --ignore-zeros
+@itemx -i
+To ignore blocks of zeros (ie.@: end-of-archive entries) which may be
+encountered while reading an archive. Use in conjunction with
+@value{op-extract} or @value{op-list}.
+@end table
+
+@node Ignore Failed Read, , Ignore Zeros, Reading
+@unnumberedsubsubsec Ignore Fail Read
+
+@FIXME{Is this in the right place? It doesn't exist anywhere else in
+the book (except the appendix), and has no further explanation. For that
+matter, what does it mean?!}
+
+@table @kbd
+@item --ignore-failed-read
+Do not exit with nonzero on unreadable files or directories.
+@end table
+
+@node Writing, Scarce, Reading, extract options
+@subsection Changing How @code{tar} Writes Files
+@cindex Overwriting old files, prevention
+@cindex Protecting old files
+@cindex Modification times of extracted files
+@cindex Permissions of extracted files
+@cindex Modes of extracted files
+@cindex Writing extracted files to standard output
+@cindex Standard output, writing extracted files to
+@UNREVISED
+
+@FIXME{need to mention the brand new option, --backup}
+
+@menu
+* Prevention Overwriting::
+* Keep Old Files::
+* Unlink First::
+* Recursive Unlink::
+* Modification Times::
+* Setting Access Permissions::
+* Writing to Standard Output::
+* remove files::
+@end menu
+
+@node Prevention Overwriting, Keep Old Files, Writing, Writing
+@unnumberedsubsubsec Options to Prevent Overwriting Files
+
+Normally, @code{tar} writes extracted files into the file system without
+regard to the files already on the system; i.e., files with the same
+names as archive members are overwritten when the archive is extracted.
+If the name of a corresponding file name is a symbolic link, the file
+pointed to by the symbolic link will be overwritten instead of the
+symbolic link itself (if this is possible). Moreover, special devices,
+empty directories and even symbolic links are automatically removed if
+they are found to be on the way of the proper extraction.
+
+To prevent @code{tar} from extracting an archive member from an archive
+if doing so will overwrite a file in the file system, use
+@value{op-keep-old-files} in conjunction with @samp{--extract}. When
+this option is specified, @code{tar} will report an error stating the
+name of the files in conflict instead of overwriting the file with the
+corresponding extracted archive member.
+
+@FIXME{these two P's have problems. i don't understand what they're
+trying to talk about well enough to fix them; i may have just made them
+worse (in particular the first of the two). waiting to talk with hag.}
+
+The @value{op-unlink-first} option removes existing files, symbolic links,
+empty directories, devices, etc., @emph{prior} to extracting over them.
+In particular, using this option will prevent replacing an already existing
+symbolic link by the name of an extracted file, since the link itself
+is removed prior to the extraction, rather than the file it points to.
+On some systems, the backing store for the executable @emph{is} the
+original program text. You could use the @value{op-unlink-first} option
+to prevent segmentation violations or other woes when extracting arbitrary
+executables over currently running copies. Note that if something goes
+wrong with the extraction and you @emph{did} use this option, you might
+end up with no file at all. Without this option, if something goes wrong
+with the extraction, the existing file is not overwritten and preserved.
+
+@FIXME{huh?} If you specify the @value{op-recursive-unlink} option,
+@code{tar} removes @emph{anything} that keeps you from extracting a file
+as far as current permissions will allow it. This could include removal
+of the contents of a full directory hierarchy. For example, someone
+using this feature may be very surprised at the results when extracting
+a directory entry from the archive. This option can be dangerous; be
+very aware of what you are doing if you choose to use it.
+
+@menu
+* Keep Old Files::
+* Unlink First::
+* Recursive Unlink::
+@end menu
+
+@node Keep Old Files, Unlink First, Prevention Overwriting, Writing
+@unnumberedsubsubsec Keep Old Files
+
+@table @kbd
+@item --keep-old-files
+@itemx -k
+Do not overwrite existing files from archive. The
+@value{op-keep-old-files} option prevents @code{tar} from over-writing
+existing files with files with the same name from the archive.
+The @value{op-keep-old-files} option is meaningless with @value{op-list}.
+Prevents @code{tar} from overwriting files in the file system during
+extraction.
+@end table
+
+@node Unlink First, Recursive Unlink, Keep Old Files, Writing
+@unnumberedsubsubsec Unlink First
+
+@table @kbd
+@item --unlink-first
+@itemx -U
+Try removing files before extracting over them, instead of trying to
+overwrite them.
+@end table
+
+@node Recursive Unlink, Modification Times, Unlink First, Writing
+@unnumberedsubsubsec Recursive Unlink
+
+@table @kbd
+@item --recursive-unlink
+When this option is specified, try removing files and directory hierarchies
+before extracting over them. @emph{This is a dangerous option!}
+@end table
+
+Some people argue that GNU @code{tar} should not hesitate to overwrite
+files with other files when extracting. When extracting a @code{tar}
+archive, they expect to see a faithful copy of the state of the filesystem
+when the archive was created. It is debatable that this would always
+be a proper behaviour. For example, suppose one has an archive in
+which @file{usr/local} is a link to @file{usr/local2}. Since then,
+maybe the site removed the link and renamed the whole hierarchy from
+@file{/usr/local2} to @file{/usr/local}. Such things happen all the time.
+I guess it would not be welcome at all that GNU @code{tar} removes the
+whole hierarchy just to make room for the link to be reinstated (unless it
+@emph{also} simultaneously restores the full @file{/usr/local2}, of course!
+GNU @code{tar} is indeed able to remove a whole hierarchy to reestablish a
+symbolic link, for example, but @emph{only if} @value{op-recursive-unlink}
+is specified to allow this behaviour. In any case, single files are
+silently removed.
+
+@node Modification Times, Setting Access Permissions, Recursive Unlink, Writing
+@unnumberedsubsubsec Setting Modification Times
+
+Normally, @code{tar} sets the modification times of extracted files to
+the modification times recorded for the files in the archive, but
+limits the permissions of extracted files by the current @code{umask}
+setting.
+
+To set the modification times of extracted files to the time when
+the files were extracted, use the @value{op-touch} option in
+conjunction with @value{op-extract}.
+
+@table @kbd
+@item --touch
+@itemx -m
+Sets the modification time of extracted archive members to the time
+they were extracted, not the time recorded for them in the archive.
+Use in conjunction with @value{op-extract}.
+@end table
+
+@node Setting Access Permissions, Writing to Standard Output, Modification Times, Writing
+@unnumberedsubsubsec Setting Access Permissions
+
+To set the modes (access permissions) of extracted files to those
+recorded for those files in the archive, use @samp{--same-persmissions}
+in conjunction with the @value{op-extract} operation. @FIXME{Should be
+aliased to ignore-umask.}
+
+@table @kbd
+@item --preserve-permission
+@itemx --same-permission
+@itemx --ignore-umask
+@itemx -p
+Set modes of extracted archive members to those recorded in the
+archive, instead of current umask settings. Use in conjunction with
+@value{op-extract}.
+@end table
+
+@FIXME{Following paragraph needs to be rewritten: why doesnt' this cat
+files together, why is this useful. is it really useful with
+more than one file?}
+
+@node Writing to Standard Output, remove files, Setting Access Permissions, Writing
+@unnumberedsubsubsec Writing to Standard Output
+
+To write the extracted files to the standard output, instead of
+creating the files on the file system, use @value{op-to-stdout} in
+conjunction with @value{op-extract}. This option is useful if you are
+extracting files to send them through a pipe, and do not need to
+preserve them in the file system. If you extract multiple members,
+they appear on standard output concatenated, in the order they are
+found in the archive.
+
+@table @kbd
+@item --to-stdout
+@itemx -O
+Writes files to the standard output. Used in conjunction with
+@value{op-extract}. Extract files to standard output. When this option
+is used, instead of creating the files specified, @code{tar} writes
+the contents of the files extracted to its standard output. This may
+be useful if you are only extracting the files in order to send them
+through a pipe. This option is meaningless with @value{op-list}.
+@end table
+
+@FIXME{Why would you want to do such a thing, how are files separated on
+the standard output? is this useful with more that one file? Are
+pipes the real reason?}
+
+@node remove files, , Writing to Standard Output, Writing
+@unnumberedsubsubsec Removing Files
+
+@FIXME{the various macros in the front of the manual think that this
+option goes in this section. i have no idea; i only know it's nowhere
+else in the book...}
+
+@table @kbd
+@item --remove-files
+Remove files after adding them to the archive.
+@end table
+
+@node Scarce, , Writing, extract options
+@subsection Coping with Scarce Resources
+@cindex Middle of the archive, starting in the
+@cindex Running out of space during extraction
+@cindex Disk space, running out of
+@cindex Space on the disk, recovering from lack of
+@UNREVISED
+
+@menu
+* Starting File::
+* Same Order::
+@end menu
+
+@node Starting File, Same Order, Scarce, Scarce
+@unnumberedsubsubsec Starting File
+
+@table @kbd
+@item --starting-file=@var{name}
+@itemx -K @var{name}
+Starts an operation in the middle of an archive. Use in conjunction
+with @value{op-extract} or @value{op-list}.
+@end table
+
+If a previous attempt to extract files failed due to lack of disk
+space, you can use @value{op-starting-file} to start extracting only
+after member @var{name} of the archive. This assumes, of course, that
+there is now free space, or that you are now extracting into a
+different file system. (You could also choose to suspend @code{tar},
+remove unnecessary files from the file system, and then restart the
+same @code{tar} operation. In this case, @value{op-starting-file} is
+not necessary. @value{xref-incremental}, @value{xref-interactive},
+and @value{ref-exclude}.)
+
+@node Same Order, , Starting File, Scarce
+@unnumberedsubsubsec Same Order
+
+@table @kbd
+@item --same-order
+@itemx --preserve-order
+@itemx -s
+To process large lists of file names on machines with small amounts of
+memory. Use in conjunction with @value{op-compare},
+@value{op-list}
+or @value{op-extract}.
+@end table
+
+@FIXME{we don't need/want --preserve to exist any more (from melissa:
+ie, don't want that *version* of the option to exist, or don't want
+the option to exist in either version?}
+
+@FIXME{i think this explanation is lacking.}
+
+The @value{op-same-order} option tells @code{tar} that the list of file
+names to be listed or extracted is sorted in the same order as the
+files in the archive. This allows a large list of names to be used,
+even on a small machine that would not otherwise be able to hold all
+the names in memory at the same time. Such a sorted list can easily be
+created by running @samp{tar -t} on the archive and editing its output.
+
+This option is probably never needed on modern computer systems.
+
+@node backup, Applications, extract options, operations
+@section Backup options
+
+@cindex backup options
+
+GNU @code{tar} offers options for making backups of files before writing
+new versions. These options control the details of these backups.
+They may apply to the archive itself before it is created or rewritten,
+as well as individual extracted members. Other GNU programs (@code{cp},
+@code{install}, @code{ln}, and @code{mv}, for example) offer similar
+options.
+
+Backup options may prove unexpectedly useful when extracting archives
+containing many members having identical name, or when extracting archives
+on systems having file name limitations, making different members appear
+has having similar names through the side-effect of name truncation.
+(This is true only if we have a good scheme for truncated backup names,
+which I'm not sure at all: I suspect work is needed in this area.)
+When any existing file is backed up before being overwritten by extraction,
+then clashing files are automatically be renamed to be unique, and the
+true name is kept for only the last file of a series of clashing files.
+By using verbose mode, users may track exactly what happens.
+
+At the detail level, some decisions are still experimental, and may
+change in the future, we are waiting comments from our users. So, please
+do not learn to depend blindly on the details of the backup features.
+For example, currently, directories themselves are never renamed through
+using these options, so, extracting a file over a directory still has
+good chances to fail. Also, backup options apply to created archives,
+not only to extracted members. For created archives, backups will not
+be attempted when the archive is a block or character device, or when it
+refers to a remote file.
+
+For the sake of simplicity and efficiency, backups are made by renaming old
+files prior to creation or extraction, and not by copying. The original
+name is restored if the file creation fails. If a failure occurs after a
+partial extraction of a file, both the backup and the partially extracted
+file are kept.
+
+@table @samp
+
+@item --backup
+@opindex --backup
+@cindex backups, making
+Make backups of files that are about to be overwritten or removed.
+Without this option, the original versions are destroyed.
+
+@item --suffix=@var{suffix}
+@opindex --suffix
+@cindex backup suffix
+@vindex SIMPLE_BACKUP_SUFFIX
+Append @var{suffix} to each backup file made with @samp{-b}. If this
+option is not specified, the value of the @code{SIMPLE_BACKUP_SUFFIX}
+environment variable is used. And if @code{SIMPLE_BACKUP_SUFFIX} is not
+set, the default is @samp{~}, just as in Emacs.
+
+@item --version-control=@var{method}
+@opindex --version-control
+@vindex VERSION_CONTROL
+@cindex backup files, type made
+Use @var{method} to determine the type of backups made with @value{op-backup}.
+If this option is not specified, the value of the @code{VERSION_CONTROL}
+environment variable is used. And if @code{VERSION_CONTROL} is not set,
+the default backup type is @samp{existing}.
+
+@vindex version-control @r{Emacs variable}
+This option corresponds to the Emacs variable @samp{version-control};
+the same values for @var{method} are accepted as in Emacs. This options
+also more descriptive name. The valid @var{method}s (unique
+abbreviations are accepted):
+
+@table @samp
+@item t
+@itemx numbered
+@opindex numbered @r{backup method}
+Always make numbered backups.
+
+@item nil
+@itemx existing
+@opindex existing @r{backup method}
+Make numbered backups of files that already have them, simple backups
+of the others.
+
+@item never
+@itemx simple
+@opindex simple @r{backup method}
+Always make simple backups.
+
+@end table
+
+@end table
+
+Some people express the desire to @emph{always} use the @var{op-backup}
+option, by defining some kind of alias or script. This is not as easy
+as one may thing, due to the fact old style options should appear first
+and consume arguments a bit inpredictably for an alias or script. But,
+if you are ready to give up using old style options, you may resort to
+using something like (a Bourne shell function here):
+
+@example
+tar () @{ /usr/local/bin/tar --backup $*; @}
+@end example
+
+@node Applications, looking ahead, backup, operations
+@section Notable @code{tar} Usages
+@UNREVISED
+
+@FIXME{Using Unix file linking capability to recreate directory
+structures---linking files into one subdirectory and then
+@code{tar}ring that directory.}
+
+@FIXME{Nice hairy example using absolute-names, newer, etc.}
+
+@findex uuencode
+You can easily use archive files to transport a group of files from
+one system to another: put all relevant files into an archive on one
+computer system, transfer the archive to another system, and extract
+the contents there. The basic transfer medium might be magnetic tape,
+Internet FTP, or even electronic mail (though you must encode the
+archive with @code{uuencode} in order to transport it properly by
+mail). Both machines do not have to use the same operating system, as
+long as they both support the @code{tar} program.
+
+For example, here is how you might copy a directory's contents from
+one disk to another, while preserving the dates, modes, owners and
+link-structure of all the files therein. In this case, the transfer
+medium is a @dfn{pipe}, which is one a Unix redirection mechanism:
+
+@smallexample
+$ @kbd{cd sourcedir; tar -cf - . | (cd targetdir; tar -xf -)}
+@end smallexample
+
+@noindent
+The command also works using short option forms:
+
+@FIXME{The following using standard input/output correct??}
+@smallexample
+$ @w{@kbd{cd sourcedir; tar --create --file=- . | (cd targetdir; tar --extract --file=-)}}
+@end smallexample
+
+@noindent
+This is one of the easiest methods to transfer a @code{tar} archive.
+
+@node looking ahead, , Applications, operations
+@section Looking Ahead: The Rest of this Manual
+
+You have now seen how to use all eight of the operations available to
+@code{tar}, and a number of the possible options. The next chapter
+explains how to choose and change file and archive names, how to use
+files to store names of other files which you can then call as
+arguments to @code{tar} (this can help you save time if you expect to
+archive the same list of files a number of times), and how to
+@FIXME{in case it's not obvious, i'm making this up in some sense
+based on my imited memory of what the next chapter *really* does. i
+just wanted to flesh out this final section a little bit so i'd
+remember to sitck it in here. :-)}
+
+If there are too many files to conveniently list on the command line,
+you can list the names in a file, and @code{tar} will read that file.
+@value{xref-files-from}.
+
+There are various ways of causing @code{tar} to skip over some files,
+and not archive them. @xref{Choosing}.
+
+@node Backups, Choosing, operations, Top
+@chapter Performing Backups and Restoring Files
+@UNREVISED
+
+GNU @code{tar} is distributed along with the scripts which the Free
+Software Foundation uses for performing backups. There is no corresponding
+scripts available yet for doing restoration of files. Even if there is
+a good chance those scripts may be satisfying to you, they are not the
+only scripts or methods available for doing backups and restore. You may
+well create your own, or use more sophisticated packages dedicated to
+that purpose.
+
+Some users are enthusiastic about @code{Amanda} (The Advanced Maryland
+Automatic Network Disk Archiver), a backup system developed by James
+da Silva @file{jds@@cs.umd.edu} and available on many Unix systems.
+This is free software, and it is available at these places:
+
+@example
+http://www.cs.umd.edu/projects/amanda/amanda.html
+ftp://ftp.cs.umd.edu/pub/amanda
+@end example
+
+@ifclear PUBLISH
+
+Here is a possible plan for a future documentation about the backuping
+scripts which are provided within the GNU @code{tar} distribution.
+
+@example
+.* dumps
+. + what are dumps
+
+. + different levels of dumps
+. - full dump = dump everything
+. - level 1, level 2 dumps etc, -
+ A level n dump dumps everything changed since the last level
+ n-1 dump (?)
+
+. + how to use scripts for dumps (ie, the concept)
+. - scripts to run after editing backup specs (details)
+
+. + Backup Specs, what is it.
+. - how to customize
+. - actual text of script [/sp/dump/backup-specs]
+
+. + Problems
+. - rsh doesn't work
+. - rtape isn't installed
+. - (others?)
+
+. + the --incremental option of tar
+
+. + tapes
+. - write protection
+. - types of media
+. : different sizes and types, useful for different things
+. - files and tape marks
+ one tape mark between files, two at end.
+. - positioning the tape
+ MT writes two at end of write,
+ backspaces over one when writing again.
+@end example
+
+@end ifclear
+
+This chapter documents both the provided FSF scripts and @code{tar}
+options which are more specific to usage as a backup tool.
+
+To @dfn{back up} a file system means to create archives that contain
+all the files in that file system. Those archives can then be used to
+restore any or all of those files (for instance if a disk crashes or a
+file is accidently deleted). File system @dfn{backups} are also
+called @dfn{dumps}.
+
+@menu
+* Full Dumps:: Using @code{tar} to Perform Full Dumps
+* Inc Dumps:: Using @code{tar} to Perform Incremental Dumps
+* incremental and listed-incremental:: The Incremental Options
+* Backup Levels:: Levels of Backups
+* Backup Parameters:: Setting Parameters for Backups and Restoration
+* Scripted Backups:: Using the Backup Scripts
+* Scripted Restoration:: Using the Restore Script
+@end menu
+
+@node Full Dumps, Inc Dumps, Backups, Backups
+@section Using @code{tar} to Perform Full Dumps
+@UNREVISED
+
+@cindex full dumps
+@cindex dumps, full
+
+@cindex corrupted archives
+Full dumps should only be made when no other people or programs
+are modifying files in the filesystem. If files are modified while
+@code{tar} is making the backup, they may not be stored properly in
+the archive, in which case you won't be able to restore them if you
+have to. (Files not being modified are written with no trouble, and do
+not corrupt the entire archive.)
+
+You will want to use the @value{op-label} option to give the archive a
+volume label, so you can tell what this archive is even if the label
+falls off the tape, or anything like that.
+
+Unless the filesystem you are dumping is guaranteed to fit on
+one volume, you will need to use the @value{op-multi-volume} option.
+Make sure you have enough tapes on hand to complete the backup.
+
+If you want to dump each filesystem separately you will need to use
+the @value{op-one-file-system} option to prevent @code{tar} from crossing
+filesystem boundaries when storing (sub)directories.
+
+The @value{op-incremental} option is not needed, since this is a complete
+copy of everything in the filesystem, and a full restore from this
+backup would only be done onto a completely empty disk.
+
+Unless you are in a hurry, and trust the @code{tar} program (and your
+tapes), it is a good idea to use the @value{op-verify} option, to make
+sure your files really made it onto the dump properly. This will
+also detect cases where the file was modified while (or just after)
+it was being archived. Not all media (notably cartridge tapes) are
+capable of being verified, unfortunately.
+
+@value{op-listed-incremental} take a file name argument always. If the
+file doesn't exist, run a level zero dump, creating the file. If the
+file exists, uses that file to see what has changed.
+
+@value{op-incremental} @FIXME{look it up}
+
+@value{op-incremental} handle old GNU-format incremental backup.
+
+This option should only be used when creating an incremental backup of
+a filesystem. When the @value{op-incremental} option is used, @code{tar}
+writes, at the beginning of the archive, an entry for each of the
+directories that will be operated on. The entry for a directory
+includes a list of all the files in the directory at the time the
+dump was done, and a flag for each file indicating whether the file
+is going to be put in the archive. This information is used when
+doing a complete incremental restore.
+
+Note that this option causes @code{tar} to create a non-standard
+archive that may not be readable by non-GNU versions of the @code{tar}
+program.
+
+The @value{op-incremental} option means the archive is an incremental
+backup. Its meaning depends on the command that it modifies.
+
+If the @value{op-incremental} option is used with @value{op-list}, @code{tar}
+will list, for each directory in the archive, the list of files in
+that directory at the time the archive was created. This information
+is put out in a format that is not easy for humans to read, but which
+is unambiguous for a program: each file name is preceded by either a
+@samp{Y} if the file is present in the archive, an @samp{N} if the
+file is not included in the archive, or a @samp{D} if the file is
+a directory (and is included in the archive). Each file name is
+terminated by a null character. The last file is followed by an
+additional null and a newline to indicate the end of the data.
+
+If the @value{op-incremental} option is used with @value{op-extract}, then
+when the entry for a directory is found, all files that currently
+exist in that directory but are not listed in the archive @emph{are
+deleted from the directory}.
+
+This behavior is convenient when you are restoring a damaged file
+system from a succession of incremental backups: it restores the
+entire state of the file system to that which obtained when the backup
+was made. If you don't use @value{op-incremental}, the file system will
+probably fill up with files that shouldn't exist any more.
+
+@value{op-listed-incremental} handle new GNU-format incremental backup.
+This option handles new GNU-format incremental backup. It has much the
+same effect as @value{op-incremental}, but also the time when the dump
+is done and the list of directories dumped is written to the given
+@var{file}. When restoring, only files newer than the saved time are
+restored, and the direcotyr list is used to speed up operations.
+
+@value{op-listed-incremental} acts like @value{op-incremental}, but when
+used in conjunction with @value{op-create} will also cause @code{tar} to
+use the file @var{file}, which contains information about the state
+of the filesystem at the time of the last backup, to decide which
+files to include in the archive being created. That file will then
+be updated by @code{tar}. If the file @var{file} does not exist when
+this option is specified, @code{tar} will create it, and include all
+appropriate files in the archive.
+
+The file, which is archive independent, contains the date it was last
+modified and a list of devices, inode numbers and directory names.
+@code{tar} will archive files with newer mod dates or inode change
+times, and directories with an unchanged inode number and device but
+a changed directory name. The file is updated after the files to
+be archived are determined, but before the new archive is actually
+created.
+
+GNU @code{tar} actually writes the file twice: once before the data
+and written, and once after.
+
+@node Inc Dumps, incremental and listed-incremental, Full Dumps, Backups
+@section Using @code{tar} to Perform Incremental Dumps
+@UNREVISED
+
+@cindex incremental dumps
+@cindex dumps, incremental
+
+Performing incremental dumps is similar to performing full dumps,
+although a few more options will usually be needed.
+
+You will need to use the @samp{-N @var{date}} option to tell @code{tar}
+to only store files that have been modified since @var{date}.
+@var{date} should be the date and time of the last full/incremental
+dump.
+
+A standard scheme is to do a @emph{monthly} (full) dump once a month,
+a @emph{weekly} dump once a week of everything since the last monthly
+and a @emph{daily} every day of everything since the last (weekly or
+monthly) dump.
+
+Here is a copy of the script used to dump the filesystems of the
+machines here at the Free Software Foundation. This script is run via
+@code{cron} late at night when people are least likely to be using the
+machines. This script dumps several filesystems from several machines
+at once (via NFS). The operator is responsible for ensuring that all
+the machines will be up at the time the dump happens. If a machine is
+not running, its files will not be dumped, and the next day's
+incremental dump will @emph{not} store files that would have gone onto
+that dump.
+
+@example
+#!/bin/csh
+# Dump thingie
+set now = `date`
+set then = `cat date.nfs.dump`
+/u/hack/bin/tar -c -G -v\
+ -f /dev/rtu20\
+ -b 126\
+ -N "$then"\
+ -V "Dump from $then to $now"\
+ /alpha-bits/gp\
+ /gnu/hack\
+ /hobbes/u\
+ /spiff/u\
+ /sugar-bombs/u
+echo $now > date.nfs.dump
+mt -f /dev/rtu20 rew
+@end example
+
+Output from this script is stored in a file, for the operator to
+read later.
+
+This script uses the file @file{date.nfs.dump} to store the date/time
+of the last dump.
+
+Since this is a streaming tape drive, no attempt to verify the archive
+is done. This is also why the high blocking factor (126) is used.
+The tape drive must also be rewound by the @code{mt} command after
+the dump is made.
+
+@node incremental and listed-incremental, Backup Levels, Inc Dumps, Backups
+@section The Incremental Options
+@UNREVISED
+
+@value{op-incremental} is used in conjunction with @value{op-create},
+@value{op-extract} or @value{op-list} when backing up and restoring file
+systems. An archive cannot be extracted or listed with the
+@value{op-incremental} option specified unless it was created with the
+option specified. This option should only be used by a script, not by
+the user, and is usually disregarded in favor of
+@value{op-listed-incremental}, which is described below.
+
+@value{op-incremental} in conjunction with @value{op-create} causes
+@code{tar} to write, at the beginning of the archive, an entry for
+each of the directories that will be archived. The entry for a
+directory includes a list of all the files in the directory at the
+time the archive was created and a flag for each file indicating
+whether or not the file is going to be put in the archive.
+
+Note that this option causes @code{tar} to create a non-standard
+archive that may not be readable by non-GNU versions of the @code{tar}
+program.
+
+@value{op-incremental} in conjunction with @value{op-extract} causes
+@code{tar} to read the lists of directory contents previously stored
+in the archive, @emph{delete} files in the file system that did not
+exist in their directories when the archive was created, and then
+extract the files in the archive.
+
+This behavior is convenient when restoring a damaged file system from
+a succession of incremental backups: it restores the entire state of
+the file system to that which obtained when the backup was made. If
+@value{op-incremental} isn't specified, the file system will probably
+fill up with files that shouldn't exist any more.
+
+@value{op-incremental} in conjunction with @value{op-list}, causes
+@code{tar} to print, for each directory in the archive, the list of
+files in that directory at the time the archive was created. This
+information is put out in a format that is not easy for humans to
+read, but which is unambiguous for a program: each file name is
+preceded by either a @samp{Y} if the file is present in the archive,
+an @samp{N} if the file is not included in the archive, or a @samp{D}
+if the file is a directory (and is included in the archive). Each
+file name is terminated by a null character. The last file is followed
+by an additional null and a newline to indicate the end of the data.
+
+@value{op-listed-incremental} acts like @value{op-incremental}, but when
+used in conjunction with @value{op-create} will also cause @code{tar}
+to use the file @var{snapshot-file}, which contains information about
+the state of the file system at the time of the last backup, to decide
+which files to include in the archive being created. That file will
+then be updated by @code{tar}. If the file @var{file} does not exist
+when this option is specified, @code{tar} will create it, and include
+all appropriate files in the archive.
+
+The file @var{file}, which is archive independent, contains the date
+it was last modified and a list of devices, inode numbers and
+directory names. @code{tar} will archive files with newer mod dates
+or inode change times, and directories with an unchanged inode number
+and device but a changed directory name. The file is updated after
+the files to be archived are determined, but before the new archive is
+actually created.
+
+Despite it should be obvious that a device has a non-volatile value, NFS
+devices have non-dependable values when an automounter gets in the picture.
+This led to a great deal of spurious redumping in incremental dumps,
+so it is somewhat useless to compare two NFS devices numbers over time.
+So @code{tar} now considers all NFS devices as being equal when it comes
+to comparing directories; this is fairly gross, but there does not seem
+to be a better way to go.
+
+@FIXME{this section needs to be written}
+
+@node Backup Levels, Backup Parameters, incremental and listed-incremental, Backups
+@section Levels of Backups
+@UNREVISED
+
+An archive containing all the files in the file system is called a
+@dfn{full backup} or @dfn{full dump}. You could insure your data by
+creating a full dump every day. This strategy, however, would waste a
+substantial amount of archive media and user time, as unchanged files
+are daily re-archived.
+
+It is more efficient to do a full dump only occasionally. To back up
+files between full dumps, you can a incremental dump. A @dfn{level
+one} dump archives all the files that have changed since the last full
+dump.
+
+A typical dump strategy would be to perform a full dump once a week,
+and a level one dump once a day. This means some versions of files
+will in fact be archived more than once, but this dump strategy makes
+it possible to restore a file system to within one day of accuracy by
+only extracting two archives---the last weekly (full) dump and the
+last daily (level one) dump. The only information lost would be in
+files changed or created since the last daily backup. (Doing dumps
+more than once a day is usually not worth the trouble).
+
+GNU @code{tar} comes with scripts you can use to do full and level-one
+dumps. Using scripts (shell programs) to perform backups and
+restoration is a convenient and reliable alternative to typing out
+file name lists and @code{tar} commands by hand.
+
+Before you use these scripts, you need to edit the file
+@file{backup-specs}, which specifies parameters used by the backup
+scripts and by the restore script. @FIXME{There is no such restore
+script!}. @FIXME-xref{Script Syntax}. Once the backup parameters
+are set, you can perform backups or restoration by running the
+appropriate script.
+
+The name of the restore script is @code{restore}. @FIXME{There is
+no such restore script!}. The names of the level one and full backup
+scripts are, respectively, @code{level-1} and @code{level-0}.
+The @code{level-0} script also exists under the name @code{weekly}, and
+the @code{level-1} under the name @code{daily}---these additional names
+can be changed according to your backup schedule. @FIXME-xref{Scripted
+Restoration}, for more information on running the restoration script.
+@FIXME-xref{Scripted Backups}, for more information on running the
+backup scripts.
+
+@emph{Please Note:} The backup scripts and the restoration scripts are
+designed to be used together. While it is possible to restore files by
+hand from an archive which was created using a backup script, and to create
+an archive by hand which could then be extracted using the restore script,
+it is easier to use the scripts. @FIXME{There is no such restore script!}.
+@value{xref-incremental}, and @value{xref-listed-incremental},
+before making such an attempt.
+
+@FIXME{shorten node names}
+
+@node Backup Parameters, Scripted Backups, Backup Levels, Backups
+@section Setting Parameters for Backups and Restoration
+@UNREVISED
+
+The file @file{backup-specs} specifies backup parameters for the
+backup and restoration scripts provided with @code{tar}. You must
+edit @file{backup-specs} to fit your system configuration and schedule
+before using these scripts.
+
+@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 @code{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 `TAPE_STATUS=false'.
+
+@item BLOCKING
+The blocking factor @code{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 @code{tar} on, and should
+normally be the host that actually contains the file system. However,
+the host machine must have GNU @code{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 @code{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, Script Syntax, Backup Parameters, Backup Parameters
+@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, , backup-specs example, Backup Parameters
+@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, Scripted Restoration, Backup Parameters, 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, , Scripted Backups, Backups
+@section Using the Restore Script
+@UNREVISED
+
+@ifset PUBLISH
+
+The @code{tar} distribution does not provide restoring scripts.
+
+@end ifset
+
+@ifclear PUBLISH
+
+@quotation
+@strong{Warning:} The GNU @code{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, Date input formats, Backups, Top
+@chapter Choosing Files and Names for @code{tar}
+@UNREVISED
+
+@FIXME{Melissa (still) Doesn't Really Like This ``Intro'' Paragraph!!!}
+
+Certain options to @code{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, Selecting Archive Members, Choosing, Choosing
+@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, @code{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 @code{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
+@code{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 @code{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 @code{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, @code{tar} uses the value of the
+environment variable @code{TAPE} as the file name for the archive. If
+that is not available, @code{tar} uses a default, compiled-in archive
+name, usually that for tape unit zero (ie. @file{/dev/tu00}).
+@code{tar} always needs an archive name.
+
+If you use @file{-} as an @var{archive-name}, @code{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,
+@code{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
+@code{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}}, @code{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 @code{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 @code{rsh} behavior.) It is necessary for the
+remote machine, in addition to permitting your @code{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}, GNU @code{tar}
+tries to minimize input and output operations. The Amanda backup
+system, when used with GNU @code{tar}, has an initial sizing pass which
+uses this feature.
+
+@node Selecting Archive Members, files, file, Choosing
+@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
+@code{tar} operates on, when creating or adding to an archive, or which
+archive members @code{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 @code{tar}.
+
+If you do not specify files when @code{tar} is invoked with
+@value{op-create}, @code{tar} operates on all the non-directory files in
+the working directory. If you specify either @value{op-list} or
+@value{op-extract}, @code{tar} operates on all the archive members in the
+archive. If you specify any operation other than one of these three,
+@code{tar} does nothing.
+
+By default, @code{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 @code{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, exclude, Selecting Archive Members, Choosing
+@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 @code{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 @code{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 @code{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 @code{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
+@code{tar} to specify the files from that file, @file{small-files}, to
+create the archive @file{little.tgz}. (The @samp{-z} option to
+@code{tar} compresses the archive with @code{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, , files, files
+@ifinfo
+@unnumberedsubsec @kbd{NUL} Terminated File Names
+@end ifinfo
+
+@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 GNU @code{xargs} and
+@code{cpio}, and is useful with the @samp{-print0} predicate of GNU
+@code{find}. In @code{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 @code{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 @code{find} just just
+like @samp{-print}, except that it separates files with a @kbd{NUL}
+rather than with a newline. You can then run @code{tar} with both the
+@samp{--null} and @samp{-T} options to specify that @code{tar} get the
+files from that file, @file{long-files}, to create the archive
+@file{big.tgz}. The @samp{--null} option to @code{tar} will cause
+@code{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, Wildcards, files, Choosing
+@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 @code{tar} to ignore files that match the @var{pattern}.
+@end table
+
+@findex exclude
+The @value{op-exclude} option will prevent any file or member which
+matches the shell wildcards (@var{pattern}) from being operated on
+(@var{pattern} can be a single file name or a more complex expression).
+For example, if you want to create an archive with all the contents of
+@file{/tmp} except the file @file{/tmp/foo}, you can use the command
+@samp{tar --create --file=arch.tar --exclude=foo}. You may give
+multiple @samp{--exclude} options.
+
+@table @kbd
+@item --exclude-from=@var{file}
+@itemx -X @var{file}
+Causes @code{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 shell wildcards, one per line, from @var{file}; @code{tar} will
+ignore files matching those regular expressions. Thus if @code{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
+* problems with exclude::
+@end menu
+
+@node problems with exclude, , exclude, exclude
+@unnumberedsubsec Problems with Using the @code{exclude} Options
+
+@FIXME{put in for the editor's/editors' amusement, but should be taken
+out in the final draft, just in case! : }
+
+@ignore
+subtitled: getting screwed using exclewed
+@end ignore
+
+Some users find @samp{exclude} options confusing. Here are some common
+pitfalls:
+
+@itemize @bullet
+@item
+The main operating mode of @code{tar} will always act on file names
+listed on the command line, no matter whether or not there is an
+exclusion which would otherwise affect them. In the example above, if
+you create an archive and exclude files that end with @samp{*.o}, but
+explicitly name the file @samp{catc.o} after all the options have been
+listed, @samp{catc.o} @emph{will} be included in 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 GNU @code{tar} sees wildcard characters like @samp{*}.
+If you do not do this, the shell might expand the @samp{*} itself
+using files at hand, so @code{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} -X '*/tmp/*' @var{directory}}
+@end example
+
+@noindent
+rather than:
+
+@example
+$ @kbd{tar -c -f @var{archive.tar} -X */tmp/* @var{directory}}
+@end example
+
+@item
+You must use use shell syntax, or globbing, rather than @code{regexp}
+syntax, when using exclude options in @code{tar}. If you try to use
+@code{regexp} syntax to describe files to be excluded, your command
+might fail.
+
+@item
+In earlier versions of @code{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, after, exclude, Choosing
+@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, @code{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 @code{tar} archives. This section has the
+purpose of explaining wildcard syntax for @code{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.
+
+There are some discussions floating in the air and asking for modifications
+in the way GNU @code{tar} accomplishes wildcard matches. We perceive
+any change of semantics in this area as a delicate thing to impose on
+GNU @code{tar} users. On the other hand, the GNU project should be
+progressive enough to correct any ill design: compatibility at all price
+is not always a good attitude. In conclusion, it is @emph{possible}
+that slight amendments be later brought to the previous description.
+Your opinions on the matter are welcome.
+
+@node after, recurse, Wildcards, Choosing
+@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 @code{tar} to only work on files
+whose modification or inode-changed times are newer than the @var{date}
+given. 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, @code{tar} will only extract files newer
+than the @var{date} you specify.
+
+If you only want @code{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 @code{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.
+
+@item --newer-mtime=@var{date}
+Acts like @value{op-after-date}, but only looks at modification times.
+@end table
+
+These options limit @code{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
+
+To select files newer than the modification time of a file that already
+exists, you can use the @samp{--reference} (@samp{-r}) option of GNU
+@code{date}, available in GNU shell utilities 1.13 or later. It returns
+the timestamp of that already existing file; this timestamp expands to
+become the referent date which @samp{--newer} uses to determine which
+files to archive. For example, you could say,
+
+@example
+$ @kbd{tar -cf @var{archive.tar} --newer="`date -r @var{file}`" /home}
+@end example
+
+@noindent
+which tells @FIXME{need to fill this in!}.
+
+@node recurse, one, after, Choosing
+@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, @code{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 @code{tar} to act this way.
+
+The @value{op-no-recursion} option inhibits @code{tar}'s recursive descent
+into specified directories. If you specify @samp{--no-recursion}, you can
+use the @code{find} utility for hunting through levels of directories to
+construct a list of file names which you could then pass to @code{tar}.
+@code{find} allows you to be more selective when choosing which files to
+archive; see @ref{files} for more information on using @code{find} with
+@code{tar}, or look.
+
+@table @kbd
+@item --no-recursion
+Prevents @code{tar} from recursively descending directories.
+@end table
+
+When you use @samp{--no-recursion}, GNU @code{tar} grabs directory entries
+themselves, but does not descend on them recursively. Many people use
+@code{find} for locating files they want to back up, and since
+@code{tar} @emph{usually} recursively descends on directories, they have
+to use the @samp{@w{! -d}} option to @code{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-file-from}
+option to archive the files located via @code{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 @code{tar} to grab only the directory entries given to it, adding
+no new files on its own.
+
+@FIXME{example here}
+
+@node one, , recurse, Choosing
+@section Crossing Filesystem Boundaries
+@cindex File system boundaries, not crossing
+@UNREVISED
+
+@code{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 @code{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;
+@code{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 @code{tar} from crossing file system boundaries when
+archiving. Use in conjunction with any write operation.
+@end table
+
+The @samp{--one-file-system} option causes @code{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
+@code{tar} will not archive that file. If the file is a directory
+itself, @code{tar} will not archive anything beneath it; in other words,
+@code{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, absolute, one, one
+@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 @code{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, , directory, one
+@subsection Absolute File Names
+@UNREVISED
+
+@table @kbd
+@item -P
+@itemx --absolute-names
+Do not strip leading slashes from file names.
+@end table
+
+By default, GNU @code{tar} drops a leading @samp{/} on input or output.
+This option turns off this behavior; it is equivalent to changing to the
+root directory before running @code{tar} (except it also turns off the
+usual warning message).
+
+When @code{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}, @code{tar} will extract it as if the name were
+really @file{etc/passwd}.
+
+Other @code{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-GNU @code{tar} program to use. Therefore,
+GNU @code{tar} also strips leading slashes from member names when
+putting members into the archive. For example, if you ask @code{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, @code{tar} will do
+neither of these transformations.
+
+To archive or extract files relative to the root directory, specify
+the @value{op-absolute-names} option.
+
+Normally, @code{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}, @code{tar} stores file names
+including all superior directory names, and preserves leading slashes.
+If you only invoked @code{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 (inclusing superior dirctory names) when
+archiving files. Preserves leading slash when extracting files.
+
+@end table
+
+@FIXME{this is still horrible; need to talk with dan on monday.}
+
+@code{tar} prints out a message about removing the @samp{/} from file
+names. This message appears once per GNU @code{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 @code{tar} standard
+error to the sink. For example, under @code{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
+
+@node Date input formats, Formats, Choosing, Top
+@chapter Date input formats
+
+@cindex date input formats
+@findex getdate
+
+@quotation
+Our units of temporal measurement, from seconds on up to months, are so
+complicated, asymmetrical and disjunctive so as to make coherent mental
+reckoning in time all but impossible. Indeed, had some tyrannical god
+contrived to enslave our minds to time, to make it all but impossible
+for us to escape subjection to sodden routines and unpleasant surprises,
+he could hardly have done better than handing down our present system.
+It is like a set of trapezoidal building blocks, with no vertical or
+horizontal surfaces, like a language in which the simplest thought
+demands ornate constructions, useless particles and lengthy
+circumlocutions. Unlike the more successful patterns of language and
+science, which enable us to face experience boldly or at least
+level-headedly, our system of temporal calculation silently and
+persistently encourages our terror of time.
+
+@dots{} It is as though architects had to measure length in feet, width
+in meters and height in ells; as though basic instruction manuals
+demanded a knowledge of five different languages. It is no wonder then
+that we often look into our own immediate past or future, last Tuesday
+or a week from Sunday, with feelings of helpless confusion. @dots{}
+
+--- Robert Grudin, @cite{Time and the Art of Living}.
+@end quotation
+
+This section describes the textual date representations that GNU
+programs accept. These are the strings you, as a user, can supply as
+arguments to the various programs. The C interface (via the
+@code{getdate} function) is not described here.
+
+@cindex beginning of time, for Unix
+@cindex epoch, for Unix
+Although the date syntax here can represent any possible time since zero
+A.D., computer integers are not big enough for such a (comparatively)
+long time. The earliest date semantically allowed on Unix systems is
+midnight, 1 January 1970 UCT.
+
+@menu
+* General date syntax:: Common rules.
+* Calendar date item:: 19 Dec 1994.
+* Time of day item:: 9:20pm.
+* Timezone item:: EST, DST, BST, UCT, AHST, ...
+* Day of week item:: Monday and others.
+* Relative item in date strings:: next tuesday, 2 years ago.
+* Pure numbers in date strings:: 19931219, 1440.
+* Authors of getdate:: Bellovin, Salz, Berets, et al.
+@end menu
+
+
+@node General date syntax, Calendar date item, Date input formats, Date input formats
+@section General date syntax
+
+@cindex general date syntax
+
+@cindex items in date strings
+A @dfn{date} is a string, possibly empty, containing many items
+separated by whitespace. The whitespace may be omitted when no
+ambiguity arises. The empty string means the beginning of today (i.e.,
+midnight). Order of the items is immaterial. A date string may contain
+many flavors of items:
+
+@itemize @bullet
+@item calendar date items
+@item time of the day items
+@item time zone items
+@item day of the week items
+@item relative items
+@item pure numbers.
+@end itemize
+
+@noindent We describe each of these item types in turn, below.
+
+@cindex numbers, written-out
+@cindex ordinal numbers
+@findex first @r{in date strings}
+@findex next @r{in date strings}
+@findex last @r{in date strings}
+A few numbers may be written out in words in most contexts. This is
+most useful for specifying day of the week items or relative items (see
+below). Here is the list: @samp{first} for 1, @samp{next} for 2,
+@samp{third} for 3, @samp{fourth} for 4, @samp{fifth} for 5,
+@samp{sixth} for 6, @samp{seventh} for 7, @samp{eighth} for 8,
+@samp{ninth} for 9, @samp{tenth} for 10, @samp{eleventh} for 11 and
+@samp{twelfth} for 12. Also, @samp{last} means exactly @math{-1}.
+
+@cindex months, written-out
+When a month is written this way, it is still considered to be written
+numerically, instead of being ``spelled in full''; this changes the
+allowed strings.
+
+@cindex case, ignored in dates
+@cindex comments, in dates
+Alphabetic case is completely ignored in dates. Comments may be introduced
+between round parentheses, as long as included parentheses are properly
+nested. Hyphens not followed by a digit are currently ignored. Leading
+zeros on numbers are ignored.
+
+
+@node Calendar date item, Time of day item, General date syntax, Date input formats
+@section Calendar date item
+
+@cindex calendar date item
+
+A @dfn{calendar date item} specifies a day of the year. It is
+specified differently, depending on whether the month is specified
+numerically or literally. All these strings specify the same calendar date:
+
+@example
+1970-09-17 # ISO 8601.
+70-9-17 # This century assumed by default.
+70-09-17 # Leading zeros are ignored.
+9/17/72 # Common U.S. writing.
+24 September 1972
+24 Sept 72 # September has a special abbreviation.
+24 Sep 72 # Three-letter abbreviations always allowed.
+Sep 24, 1972
+24-sep-72
+24sep72
+@end example
+
+The year can also be omitted. In this case, the last specified year is
+used, or the current year if none. For example:
+
+@example
+9/17
+sep 17
+@end example
+
+Here are the rules.
+
+@cindex ISO 8601 date format
+@cindex date format, ISO 8601
+For numeric months, the ISO 8601 format
+@samp{@var{year}-@var{month}-@var{day}} is allowed, where @var{year} is
+any positive number, @var{month} is a number between 01 and 12, and
+@var{day} is a number between 01 and 31. A leading zero must be present
+if a number is less than ten. If @var{year} is less than 100, then 1900
+is added to it to force a date in this century. The construct
+@samp{@var{month}/@var{day}/@var{year}}, popular in the United States,
+is accepted. Also @samp{@var{month}/@var{day}}, omitting the year.
+
+@cindex month names in date strings
+@cindex abbreviations for months
+Literal months may be spelled out in full: @samp{January},
+@samp{February}, @samp{March}, @samp{April}, @samp{May}, @samp{June},
+@samp{July}, @samp{August}, @samp{September}, @samp{October},
+@samp{November} or @samp{December}. Literal months may be abbreviated
+to their first three letters, possibly followed by an abbreviating dot.
+It is also permitted to write @samp{Sept} instead of @samp{September}.
+
+When months are written literally, the calendar date may be given as any
+of the following:
+
+@example
+@var{day} @var{month} @var{year}
+@var{day} @var{month}
+@var{month} @var{day} @var{year}
+@var{day}-@var{month}-@var{year}
+@end example
+
+Or, omitting the year:
+
+@example
+@var{month} @var{day}
+@end example
+
+
+@node Time of day item, Timezone item, Calendar date item, Date input formats
+@section Time of day item
+
+@cindex time of day item
+
+A @dfn{time of day item} in date strings specifies the time on a given
+day. Here are some examples, all of which represent the same time:
+
+@example
+20:02:0
+20:02
+8:02pm
+20:02-0500 # In EST (Eastern U.S. Standard Time).
+@end example
+
+More generally, the time of the day may be given as
+@samp{@var{hour}:@var{minute}:@var{second}}, where @var{hour} is
+a number between 0 and 23, @var{minute} is a number between 0 and
+59, and @var{second} is a number between 0 and 59. Alternatively,
+@samp{:@var{second}} can be omitted, in which case it is taken to
+be zero.
+
+@findex am @r{in date strings}
+@findex pm @r{in date strings}
+@findex midnight @r{in date strings}
+@findex noon @r{in date strings}
+If the time is followed by @samp{am} or @samp{pm} (or @samp{a.m.}
+or @samp{p.m.}), @var{hour} is restricted to run from 1 to 12, and
+@samp{:@var{minute}} may be omitted (taken to be zero). @samp{am}
+indicates the first half of the day, @samp{pm} indicates the second
+half of the day. In this notation, 12 is the predecessor of 1:
+midnight is @samp{12am} while noon is @samp{12pm}.
+
+@cindex timezone correction
+@cindex minutes, timezone correction by
+The time may alternatively be followed by a timezone correction,
+expressed as @samp{@var{s}@var{hh}@var{mm}}, where @var{s} is @samp{+}
+or @samp{-}, @var{hh} is a number of zone hours and @var{mm} is a number
+of zone minutes. When a timezone correction is given this way, it
+forces interpretation of the time in UTC, overriding any previous
+specification for the timezone or the local timezone. The @var{minute}
+part of the time of the day may not be elided when a timezone correction
+is used. This is the only way to specify a timezone correction by
+fractional parts of an hour.
+
+Either @samp{am}/@samp{pm} or a timezone correction may be specified,
+but not both.
+
+
+@node Timezone item, Day of week item, Time of day item, Date input formats
+@section Timezone item
+
+@cindex timezone item
+
+A @dfn{timezone item} specifies an international timezone, indicated by
+a small set of letters. Any included period is ignored. Military
+timezone designations use a single letter. Currently, only integral
+zone hours may be represented in a timezone item. See the previous
+section for a finer control over the timezone correction.
+
+Here are many non-daylight-savings-time timezones, indexed by the zone
+hour value.
+
+@table @asis
+@item +000
+@cindex Greenwich Mean Time
+@cindex Universal Coordinated Time
+@cindex Western European Time
+@samp{GMT} for Greenwich Mean, @samp{UT} or @samp{UTC} for Universal
+(Coordinated), @samp{WET} for Western European and @samp{Z} for
+militaries.
+@item +100
+@cindex West African Time
+@samp{WAT} for West Africa and
+@samp{A} for militaries.
+@item +200
+@cindex Azores Time
+@samp{AT} for Azores and @samp{B} for militaries.
+@item +300
+@samp{C} for militaries.
+@item +400
+@cindex Atlantic Standard Time
+@samp{AST} for Atlantic Standard and @samp{D} for militaries.
+@item +500
+@cindex Eastern Standard Time
+@samp{E} for militaries and @samp{EST} for Eastern Standard.
+@item +600
+@cindex Central Standard Time
+@samp{CST} for Central Standard and @samp{F} for militaries.
+@item +700
+@cindex Mountain Standard Time
+@samp{G} for militaries and @samp{MST} for Mountain Standard.
+@item +800
+@cindex Pacific Standard Time
+@samp{H} for militaries and @samp{PST} for Pacific Standard.
+@item +900
+@cindex Yukon Standard Time
+@samp{I} for militaries and @samp{YST} for Yukon Standard.
+@item +1000
+@cindex Alaska-Hawaii Time
+@cindex Central Alaska Time
+@cindex Hawaii Standard Time
+@samp{AHST} for Alaska-Hawaii Standard, @samp{CAT} for Central Alaska,
+@samp{HST} for Hawaii Standard and @samp{K} for militaries.
+@item +1100
+@cindex Nome Standard Time
+@samp{L} for militaries and @samp{NT} for Nome.
+@item +1200
+@cindex International Date Line West
+@samp{IDLW} for International Date Line West and @samp{M} for
+militaries.
+@item -100
+@cindex Central European Time
+@cindex Middle European Time
+@cindex Middle European Winter Time
+@cindex French Winter Time
+@cindex Swedish Winter Time
+@samp{CET} for Central European, @samp{FWT} for French Winter,
+@samp{MET} for Middle European, @samp{MEWT} for Middle European
+Winter, @samp{N} for militaries and @samp{SWT} for Swedish Winter.
+@item -200
+@cindex Eastern European Time
+@cindex USSR Zone
+@samp{EET} for Eastern European, USSR Zone 1 and @samp{O} for militaries.
+@item -300
+@cindex Baghdad Time
+@samp{BT} for Baghdad, USSR Zone 2 and @samp{P} for militaries.
+@item -400
+@samp{Q} for militaries and @samp{ZP4} for USSR Zone 3.
+@item -500
+@samp{R} for militaries and @samp{ZP5} for USSR Zone 4.
+@item -600
+@samp{S} for militaries and @samp{ZP6} for USSR Zone 5.
+@item -700
+@cindex West Australian Standard Time
+@samp{T} for militaries and @samp{WAST} for West Australian Standard.
+@item -800
+@cindex China Coast Time
+@samp{CCT} for China Coast, USSR Zone 7 and @samp{U} for militaries.
+@item -900
+@cindex Japan Standard Time
+@samp{JST} for Japan Standard, USSR Zone 8 and @samp{V} for militaries.
+@item -1000
+@cindex East Australian Standard Time
+@cindex Guam Standard Time
+@samp{EAST} for East Australian Standard, @samp{GST} for Guam
+Standard, USSR Zone 9 and @samp{W} for militaries.
+@item -1100
+@samp{X} for militaries.
+@item -1200
+@cindex International Date Line East
+@cindex New Zealand Standard Time
+@samp{IDLE} for International Date Line East, @samp{NZST} for
+New Zealand Standard, @samp{NZT} for New Zealand and @samp{Y} for
+militaries.
+@end table
+
+@cindex daylight savings time
+Here are many DST timezones, indexed by the zone hour value. Also, by
+following a non-DST timezone by the string @samp{DST} in a separate word
+(that is, separated by some whitespace), the corresponding DST timezone
+may be specified.
+
+@table @asis
+@item 0
+@samp{BST} for British Summer.
+@item +400
+@samp{ADT} for Atlantic Daylight.
+@item +500
+@samp{EDT} for Eastern Daylight.
+@item +600
+@samp{CDT} for Central Daylight.
+@item +700
+@samp{MDT} for Mountain Daylight.
+@item +800
+@samp{PDT} for Pacific Daylight.
+@item +900
+@samp{YDT} for Yukon Daylight.
+@item +1000
+@samp{HDT} for Hawaii Daylight.
+@item -100
+@samp{MEST} for Middle European Summer, @samp{MESZ} for Middle European
+Summer, @samp{SST} for Swedish Summer and @samp{FST} for French Summer.
+@item -700
+@samp{WADT} for West Australian Daylight.
+@item -1000
+@samp{EADT} for Eastern Australian Daylight.
+@item -1200
+@samp{NZDT} for New Zealand Daylight.
+@end table
+
+
+@node Day of week item, Relative item in date strings, Timezone item, Date input formats
+@section Day of week item
+
+@cindex day of week item
+
+The explicit mention of a day of the week will forward the date
+(only if necessary) to reach that day of the week in the future.
+
+Days of the week may be spelled out in full: @samp{Sunday},
+@samp{Monday}, @samp{Tuesday}, @samp{Wednesday}, @samp{Thursday},
+@samp{Friday} or @samp{Saturday}. Days may be abbreviated to their
+first three letters, optionally followed by a period. The special
+abbreviations @samp{Tues} for @samp{Tuesday}, @samp{Wednes} for
+@samp{Wednesday} and @samp{Thur} or @samp{Thurs} for @samp{Thursday} are
+also allowed.
+
+@findex next @var{day}
+@findex last @var{day}
+A number may precede a day of the week item to move forward
+supplementary weeks. It is best used in expression like @samp{third
+monday}. In this context, @samp{last @var{day}} or @samp{next
+@var{day}} is also acceptable; they move one week before or after
+the day that @var{day} by itself would represent.
+
+A comma following a day of the week item is ignored.
+
+
+@node Relative item in date strings, Pure numbers in date strings, Day of week item, Date input formats
+@section Relative item in date strings
+
+@cindex relative items in date strings
+@cindex displacement of dates
+
+@dfn{Relative items} adjust a date (or the current date if none) forward
+or backward. The effects of relative items accumulate. Here are some
+examples:
+
+@example
+1 year
+1 year ago
+3 years
+2 days
+@end example
+
+@findex year @r{in date strings}
+@findex month @r{in date strings}
+@findex fortnight @r{in date strings}
+@findex week @r{in date strings}
+@findex day @r{in date strings}
+@findex hour @r{in date strings}
+@findex minute @r{in date strings}
+The unit of time displacement may be selected by the string @samp{year}
+or @samp{month} for moving by whole years or months. These are fuzzy
+units, as years and months are not all of equal duration. More precise
+units are @samp{fortnight} which is worth 14 days, @samp{week} worth 7
+days, @samp{day} worth 24 hours, @samp{hour} worth 60 minutes,
+@samp{minute} or @samp{min} worth 60 seconds, and @samp{second} or
+@samp{sec} worth one second. An @samp{s} suffix on these units is
+accepted and ignored.
+
+@findex ago @r{in date strings}
+The unit of time may be preceded by a multiplier, given as an optionally
+signed number. Unsigned numbers are taken as positively signed. No
+number at all implies 1 for a multiplier. Following a relative item by
+the string @samp{ago} is equivalent to preceding the unit by a
+multiplicator with value @math{-1}.
+
+@findex day @r{in date strings}
+@findex tomorrow @r{in date strings}
+@findex yesterday @r{in date strings}
+The string @samp{tomorrow} is worth one day in the future (equivalent
+to @samp{day}), the string @samp{yesterday} is worth
+one day in the past (equivalent to @samp{day ago}).
+
+@findex now @r{in date strings}
+@findex today @r{in date strings}
+@findex this @r{in date strings}
+The strings @samp{now} or @samp{today} are relative items corresponding
+to zero-valued time displacement, these strings come from the fact
+a zero-valued time displacement represents the current time when not
+otherwise change by previous items. They may be used to stress other
+items, like in @samp{12:00 today}. The string @samp{this} also has
+the meaning of a zero-valued time displacement, but is preferred in
+date strings like @samp{this thursday}.
+
+When a relative item makes the resulting date to cross the boundary
+between DST and non-DST (or vice-versa), the hour is adjusted according
+to the local time.
+
+
+@node Pure numbers in date strings, Authors of getdate, Relative item in date strings, Date input formats
+@section Pure numbers in date strings
+
+@cindex pure numbers in date strings
+
+The precise intepretation of a pure decimal number is dependent of
+the context in the date string.
+
+If the decimal number is of the form @var{yyyy}@var{mm}@var{dd} and no
+other calendar date item (@pxref{Calendar date item}) appears before it
+in the date string, then @var{yyyy} is read as the year, @var{mm} as the
+month number and @var{dd} as the day of the month, for the specified
+calendar date.
+
+If the decimal number is of the form @var{hh}@var{mm} and no other time
+of day item appears before it in the date string, then @var{hh} is read
+as the hour of the day and @var{mm} as the minute of the hour, for the
+specified time of the day. @var{mm} can also be omitted.
+
+If both a calendar date and a time of day appear to the left of a number
+in the date string, but no relative item, then the number overrides the
+year.
+
+
+@node Authors of getdate, , Pure numbers in date strings, Date input formats
+@section Authors of @code{getdate}
+
+@cindex authors of @code{getdate}
+
+@cindex Bellovin, Steven M.
+@cindex Salz, Rich
+@cindex Berets, Jim
+@cindex MacKenzie, David
+@cindex Meyering, Jim
+@code{getdate} was originally implemented by Steven M. Bellovin
+(@samp{smb@@research.att.com}) while at the University of North Carolina
+at Chapel Hill. The code was later tweaked by a couple of people on
+Usenet, then completely overhauled by Rich $alz (@samp{rsalz@@bbn.com})
+and Jim Berets (@samp{jberets@@bbn.com}) in August, 1990. Various
+revisions for the GNU system were made by David MacKenzie, Jim Meyering,
+and others.
+
+@cindex Pinard, F.
+@cindex Berry, K.
+This chapter was originally produced by Fran@,{c}ois Pinard
+(@samp{pinard@@iro.umontreal.ca}) from the @file{getdate.y} source code,
+and then edited by K.@: Berry (@samp{kb@@cs.umb.edu}).
+
+@node Formats, Media, Date input formats, Top
+@chapter Controlling the Archive Format
+
+@FIXME{need an intro here}
+
+@menu
+* Portability:: Making @code{tar} Archives More Portable
+* Compression:: Using Less Space through Compression
+* Attributes:: Handling File Attributes
+* Standard:: The Standard Format
+* Extensions:: GNU Extensions to the Archive Format
+* cpio:: Comparison of @code{tar} and @code{cpio}
+@end menu
+
+@node Portability, Compression, Formats, Formats
+@section Making @code{tar} Archives More Portable
+
+Creating a @code{tar} archive on a particular system that is meant to be
+useful later on many other machines and with other versions of @code{tar}
+is more challenging than you might think. @code{tar} archive formats
+have been evolving since the first versions of Unix. Many such formats
+are around, and are not always comptible with each other. This section
+discusses a few problems, and gives some advice about making @code{tar}
+archives more portable.
+
+One golden rule is simplicity. For example, limit your @code{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:: POSIX archives
+* Checksumming:: Checksumming Problems
+@end menu
+
+@node Portable Names, dereference, Portability, Portability
+@subsection Portable Names
+
+Use @emph{straight} file and directory names, made up of printable
+ASCII characters, avoiding colons, slashes, backslashes, spaces, and
+other @emph{dangerous} characters. Avoid deep directory nesting.
+Accounting for oldish System V machines, limit your file and directory
+names to 14 characters or less.
+
+If you intend to have your @code{tar} archives to be read under MSDOS,
+you should not rely on case distinction for file names, and you might
+use the GNU @code{doschk} program for helping you further diagnosing
+illegal MSDOS names, which are even more limited than System V's.
+
+@node dereference, old, Portable Names, Portability
+@subsection Symbolic Links
+@cindex File names, using symbolic links
+@cindex Symbolic link as file name
+
+Normally, when @code{tar} archives a symbolic link, it writes a
+block to the archive naming the target of the link. In that way, the
+@code{tar} archive is a faithful record of the filesystem contents.
+@value{op-dereference} is used with @value{op-create}, and causes @code{tar}
+to archive the files symbolic links point to, instead of the links
+themselves. When this option is used, when @code{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 @code{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 @code{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, posix, dereference, Portability
+@subsection Old V7 Archives
+@cindex Format, old style
+@cindex Old style format
+@cindex Old style archives
+
+Certain old versions of @code{tar} cannot handle additional
+information recorded by newer @code{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}. @code{tar} also
+accepts @samp{--portability} for this option. When you specify it,
+@code{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}
+@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
+conformant 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
+
+SunOS and HP-UX @code{tar} fail to accept archives created using GNU
+@code{tar} and containing non-ASCII file names, that is, file names
+having characters with the eight bit set, because they use signed
+checksums, while GNU @code{tar} uses unsigned checksums while creating
+archives, as per POSIX standards. On reading, GNU @code{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.
+
+GNU @code{tar} compute checksums both ways, and accept any on read,
+so GNU tar can read Sun tapes even with their wrong checksums.
+GNU @code{tar} produces the standard checksum, however, raising
+incompatibilities with Sun. That is to say, GNU @code{tar} has not
+been modified to @emph{produce} incorrect archives to be read by buggy
+@code{tar}'s. I've been told that more recent Sun @code{tar} now
+read standard archives, so maybe Sun did a similar patch, after all?
+
+The story seems to be that when Sun first imported @code{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 @code{tar} archives to be compatible with Sun's.
+The current standards do not favor Sun @code{tar} format. In any
+case, it now falls on the shoulders of SunOS and HP-UX users to get
+a @code{tar} able to read the good archives they receive.
+
+@node Compression, Attributes, Portability, Formats
+@section Using Less Space through Compression
+
+@menu
+* gzip:: Creating and Reading Compressed Archives
+* sparse:: Archiving Sparse Files
+@end menu
+
+@node gzip, sparse, Compression, Compression
+@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 @code{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 @code{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 @code{gzip}
+explicitly. (Or set the @samp{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 GNU @code{tar} is to work in concert
+with @code{gzip} in a way similar to @code{zip}, say. Surely, it is
+possible that @code{tar} and @code{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
+@code{zip}, archive members are archived individually. @code{tar}'s
+method yields better compression. On the other hand, one can view the
+contents of a @code{zip} archive without having to decompress it. As
+for the @code{tar} and @code{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: @code{gzip}'ed files have no
+redundancy, for maximum compression. The adaptive nature of the
+compression scheme means that the compression tables are implicitly
+spread all over the archive. If you lose a few blocks, the dynamic
+construction of the compression tables becomes unsychronized, and there
+is little chance that you could recover later in the archive.
+
+There are pending suggestions for having a per-volume or per-file
+compression in GNU @code{tar}. This would allow for viewing the
+contents without decompression, and for resynchronizing decompression at
+every volume or file, in case of corrupted archives. Doing so, we might
+loose some compressibility. But this would have make recovering easier.
+So, there are pros and cons. We'll see!
+
+@table @kbd
+@item -Z
+@itemx --compress
+@itemx --uncompress
+Filter the archive through @code{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
+@code{tar} to compress when writing the archive, or to uncompress when
+reading the archive.
+
+To perform compression and uncompression on the archive, @code{tar}
+runs the @code{compress} utility. @code{tar} uses the default
+compression parameters; if you need to override them, avoid the
+@value{op-compress} option and run the @code{compress} utility
+explicitly. It is useful to be able to call the @code{compress}
+utility from within @code{tar} because the @code{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},
+@value{op-append} and @value{op-delete} operations. @xref{Operations}, for
+more information on these operations.
+
+If there is no compress utility available, @code{tar} will report an error.
+@strong{Please note} that the @code{compress} program may be covered by
+a patent, and therefore we recommend you stop using it.
+
+@table @kbd
+@item --compress
+@itemx --uncompress
+@itemx -z
+@itemx -Z
+When this option is specified, @code{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 @code{tar} to use the @code{gzip} program to be
+used to compress or uncompress the archive wren writing or reading it.
+
+To use the older, obsolete, @code{compress} program, use the
+@value{op-compress} option. The GNU Project recommends you not use
+@code{compress}, because there is a patent covering the algorithm it
+uses. You could be sued for patent infringment merely by running
+@code{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 GNU @code{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 @code{tar} through
+@code{ecc}, but then I lose (though I haven't started using it yet,
+I confess) the ability to have @code{tar} use @code{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 @code{ecc} but if (as the comments say) it can't
+deal with loss of block sync, I'm tempted to throw some time at adding
+that capability. Supposing I were to actually do such a thing and
+get it (apparantly) working, do you accept contributed changes to
+utilities like that? (Leigh Clayton @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, , gzip, Compression
+@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
+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, @code{tar}
+could create an archive longer than the original. To have @code{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, @code{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}, @code{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, @code{tar} tests all files for sparseness while archiving.
+If @code{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
+
+@code{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, GNU
+@code{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 Sparstation ELC, with full CPU utilisation.)
+
+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 @code{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 @code{dump} do not have to read the entire file; by examining
+the file system directly, they can determine in advance exactly where the
+holes are and thus avoid reading through them. The only data it need read
+are the actual allocated data blocks. GNU @code{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:
+
+@quotation
+What I did say is that you cannot tell the difference between a hole and an
+equivalent number of nulls without reading raw blocks. @code{st_blocks} at
+best tells you how many holes there are; it doesn't tell you @emph{where}.
+Just as programs may, conceivably, care what @code{st_blocks} is (care
+to name one that does?), they may also care where the holes are (I have
+no examples of this one either, but it's equally imaginable).
+
+I conclude from this that good archivers are not portable. One can
+arguably conclude that if you want a portable program, you can in good
+conscience restore files with as many holes as possible, since you can't
+get it right.
+@end quotation
+
+@node Attributes, Standard, Compression, Formats
+@section Handling File Attributes
+@UNREVISED
+
+When @code{tar} reads files, this causes them to have the access times
+updated. To have @code{tar} attempt to set the access times back to
+what they were before they were read, use the @value{op-atime-preserve}
+option. This doesn't work for files that you don't own, unless
+you're root, and it doesn't interact with incremental dumps nicely
+(@pxref{Backups}), but it is good enough for some purposes.
+
+Handling of file attributes
+
+@table @kbd
+@item --atime-preserve
+Do not change access times on dumped files.
+
+@item -m
+@itemx --touch
+Do not extract file modified time.
+
+When this option is used, @code{tar} leaves the modification times
+of the files it extracts as the time when the files were extracted,
+instead of setting it to the time recorded in the archive.
+
+This option is meaningless with @value{op-list}.
+
+@item --same-owner
+Create extracted files with the same ownership they have in the
+archive.
+
+When using super-user at extraction time, ownership is always restored.
+So, this option is meaningful only for non-root users, when @code{tar}
+is executed on those systems able to give files away. This is
+considered as a security flaw by many people, at least because it
+makes quite difficult to correctly account users for the disk space
+they occupy. Also, the @code{suid} or @code{sgid} attributes of
+files are easily and silently lost when files are given away.
+
+When writing an archive, @code{tar} writes the user id and user name
+separately. If it can't find a user name (because the user id is not
+in @file{/etc/passwd}), then it does not write one. When restoring,
+and doing a @code{chmod} like when you use @value{op-same-permissions}
+(@FIXME{same-owner?}), it tries to look the name (if one was written)
+up in @file{/etc/passwd}. If it fails, then it uses the user id
+stored in the archive instead.
+
+@item --numeric-owner
+The @value{op-numeric-owner} option allows (ANSI) archives to be written
+without user/group name information or such information to be ignored
+when extracting. It effectively disables the generation and/or use
+of user/group name information. This option forces extraction using
+the numeric ids from the archive, ignoring the names.
+
+This is useful in certain circumstances, when restoring a backup from
+an emergency floppy with different passwd/group files for example.
+It is otherwise impossible to extract files with the right ownerships
+if the password file in use during the extraction does not match the
+one belonging to the filesystem(s) being extracted. This occurs,
+for example, if you are restoring your files after a major crash and
+had booted from an emergency floppy with no password file or put your
+disk into another machine to do the restore.
+
+The numeric ids are @emph{always} saved into @code{tar} archives.
+The identifying names are added at create time when provided by the
+system, unless @value{op-old-archive} is used. Numeric ids could be
+used when moving archives between a collection of machines using
+a centralized management for attribution of numeric ids to users
+and groups. This is often made through using the NIS capabilities.
+
+When making a @code{tar} file for distribution to other sites, it
+is sometimes cleaner to use a single owner for all files in the
+distribution, and nicer to specify the write permission bits of the
+files as stored in the archive independently of their actual value on
+the file system. The way to prepare a clean distribution is usually
+to have some Makefile rule creating a directory, copying all needed
+files in that directory, then setting ownership and permissions as
+wanted (there are a lot of possible schemes), and only then making a
+@code{tar} archive out of this directory, before cleaning everything
+out. Of course, we could add a lot of options to GNU @code{tar} for
+fine tuning permissions and ownership. This is not the good way,
+I think. GNU @code{tar} is already crowded with options and moreover,
+the approach just explained gives you a great deal of control already.
+
+@item -p
+@itemx --same-permissions
+@itemx --preserve-permissions
+Extract all protection information.
+
+This option causes @code{tar} to set the modes (access permissions) of
+extracted files exactly as recorded in the archive. If this option
+is not used, the current @code{umask} setting limits the permissions
+on extracted files.
+
+This option is meaningless with @value{op-list}.
+
+@item --preserve
+Same as both @value{op-same-permissions} and @value{op-same-order}.
+
+The @value{op-preserve} option has no equivalent short option name.
+It is equivalent to @value{op-same-permissions} plus @value{op-same-order}.
+
+@FIXME{I do not see the purpose of such an option. (Neither I. FP.)}
+
+@end table
+
+@node Standard, Extensions, Attributes, Formats
+@section The Standard Format
+@UNREVISED
+
+While an archive may contain many files, the archive itself is a
+single ordinary file. Like any other file, an archive file can be
+written to a storage device such as a tape or disk, sent through a
+pipe or over a network, saved on the active file system, or even
+stored in another archive. An archive file is not easy to read or
+manipulate without using the @code{tar} utility or Tar mode in GNU
+Emacs.
+
+Physically, an archive consists of a series of file entries terminated
+by an end-of-archive entry, which consists of 512 zero bytes. A file
+entry usually describes one of the files in the archive (an
+@dfn{archive member}), and consists of a file header and the contents
+of the file. File headers contain file names and statistics, checksum
+information which @code{tar} uses to detect file corruption, and
+information about file types.
+
+Archives are permitted to have more than one member with the same
+member name. One way this situation can occur is if more than one
+version of a file has been stored in the archive. For information
+about adding new versions of a file to an archive, see @ref{update},
+and to learn more about having more than one archive member with the
+same name, see @FIXME-xref{-backup node, when it's written}.
+
+In addition to entries describing archive members, an archive may
+contain entries which @code{tar} itself uses to store information.
+@value{xref-label}, for an example of such an archive entry.
+
+A @code{tar} archive file contains a series of blocks. Each block
+contains @code{BLOCKSIZE} bytes. Although this format may be thought
+of as being on magnetic tape, other media are often used.
+
+Each file archived is represented by a header block which describes
+the file, followed by zero or more blocks which give the contents
+of the file. At the end of the archive file there may be a block
+filled with binary zeros as an end-of-file marker. A reasonable system
+should write a block of zeros at the end, but must not assume that
+such a block exists when reading an archive.
+
+The blocks may be @dfn{blocked} for physical I/O operations.
+Each record of @var{n} blocks (where @var{n} is set by the
+@value{op-blocking-factor} option to @code{tar}) is written with a single
+@w{@samp{write ()}} operation. On magnetic tapes, the result of
+such a write is a single record. When writing an archive,
+the last record of blocks should be written at the full size, with
+blocks after the zero block containing all zeros. When reading
+an archive, a reasonable system should properly handle an archive
+whose last record is shorter than the rest, or which contains garbage
+records after a zero block.
+
+The header block is defined in C as follows. In the GNU @code{tar}
+distribution, this is part of file @file{src/tar.h}:
+
+@example
+@include header.texi
+@end example
+
+All characters in header blocks are represented by using 8-bit
+characters in the local variant of ASCII. Each field within the
+structure is contiguous; that is, there is no padding used within
+the structure. Each character on the archive medium is stored
+contiguously.
+
+Bytes representing the contents of files (after the header block
+of each file) are not translated in any way and are not constrained
+to represent characters in any character set. The @code{tar} format
+does not distinguish text files from binary files, and no translation
+of file contents is performed.
+
+The @code{name}, @code{linkname}, @code{magic}, @code{uname}, and
+@code{gname} are null-terminated character strings. All other fileds
+are zero-filled octal numbers in ASCII. Each numeric field of width
+@var{w} contains @var{w} minus 2 digits, a space, and a null, except
+@code{size}, and @code{mtime}, which do not contain the trailing null.
+
+The @code{name} field is the file name of the file, with directory names
+(if any) preceding the file name, separated by slashes.
+
+@FIXME{how big a name before field overflows?}
+
+The @code{mode} field provides nine bits specifying file permissions
+and three bits to specify the Set UID, Set GID, and Save Text
+(@dfn{sticky}) modes. Values for these bits are defined above.
+When special permissions are required to create a file with a given
+mode, and the user restoring files from the archive does not hold such
+permissions, the mode bit(s) specifying those special permissions
+are ignored. Modes which are not supported by the operating system
+restoring files from the archive will be ignored. Unsupported modes
+should be faked up when creating or updating an archive; e.g. the
+group permission could be copied from the @emph{other} permission.
+
+The @code{uid} and @code{gid} fields are the numeric user and group
+ID of the file owners, respectively. If the operating system does
+not support numeric user or group IDs, these fields should be ignored.
+
+The @code{size} field is the size of the file in bytes; linked files
+are archived with this field specified as zero. @FIXME-xref{Modifiers}, in
+particular the @value{op-incremental} option.
+
+The @code{mtime} field is the modification time of the file at the time
+it was archived. It is the ASCII representation of the octal value of
+the last time the file was modified, represented as an integer number of
+seconds since January 1, 1970, 00:00 Coordinated Universal Time.
+
+The @code{chksum} field is the ASCII representation of the octal value
+of the simple sum of all bytes in the header block. Each 8-bit
+byte in the header is added to an unsigned integer, initialized to
+zero, the precision of which shall be no less than seventeen bits.
+When calculating the checksum, the @code{chksum} field is treated as
+if it were all blanks.
+
+The @code{typeflag} field specifies the type of file archived. If a
+particular implementation does not recognize or permit the specified
+type, the file will be extracted as if it were a regular file. As this
+action occurs, @code{tar} issues a warning to the standard error.
+
+The @code{atime} and @code{ctime} fields are used in making incremental
+backups; they store, respectively, the particular file's access time
+and last inode-change time.
+
+The @code{offset} is used by the @value{op-multi-volume} option, when
+making a multi-volume archive. The offset is number of bytes into
+the file that we need to restart at to continue the file on the next
+tape, i.e., where we store the location that a continued file is
+continued at.
+
+The following fields were added to deal with sparse files. A file
+is @dfn{sparse} if it takes in unallocated blocks which end up being
+represented as zeros, i.e., no useful data. A test to see if a file
+is sparse is to look at the number blocks allocated for it versus the
+number of characters in the file; if there are fewer blocks allocated
+for the file than would normally be allocated for a file of that
+size, then the file is sparse. This is the method @code{tar} uses to
+detect a sparse file, and once such a file is detected, it is treated
+differently from non-sparse files.
+
+Sparse files are often @code{dbm} files, or other database-type files
+which have data at some points and emptiness in the greater part of
+the file. Such files can appear to be very large when an @samp{ls
+-l} is done on them, when in truth, there may be a very small amount
+of important data contained in the file. It is thus undesirable
+to have @code{tar} think that it must back up this entire file, as
+great quantities of room are wasted on empty blocks, which can lead
+to running out of room on a tape far earlier than is necessary.
+Thus, sparse files are dealt with so that these empty blocks are
+not written to the tape. Instead, what is written to the tape is a
+description, of sorts, of the sparse file: where the holes are, how
+big the holes are, and how much data is found at the end of the hole.
+This way, the file takes up potentially far less room on the tape,
+and when the file is extracted later on, it will look exactly the way
+it looked beforehand. The following is a description of the fields
+used to handle a sparse file:
+
+The @code{sp} is an array of @code{struct sparse}. Each @code{struct
+sparse} contains two 12-character strings which represent an offset
+into the file and a number of bytes to be written at that offset.
+The offset is absolute, and not relative to the offset in preceding
+array element.
+
+The header can hold four of these @code{struct sparse} at the moment;
+if more are needed, they are not stored in the header.
+
+The @code{isextended} flag is set when an @code{extended_header}
+is needed to deal with a file. Note that this means that this flag
+can only be set when dealing with a sparse file, and it is only set
+in the event that the description of the file will not fit in the
+alloted room for sparse structures in the header. In other words,
+an extended_header is needed.
+
+The @code{extended_header} structure is used for sparse files which
+need more sparse structures than can fit in the header. The header can
+fit 4 such structures; if more are needed, the flag @code{isextended}
+gets set and the next block is an @code{extended_header}.
+
+Each @code{extended_header} structure contains an array of 21
+sparse structures, along with a similar @code{isextended} flag
+that the header had. There can be an indeterminate number of such
+@code{extended_header}s to describe a sparse file.
+
+@table @asis
+
+@item @code{REGTYPE}
+@itemx @code{AREGTYPE}
+These flags represent a regular file. In order to be compatible
+with older versions of @code{tar}, a @code{typeflag} value of
+@code{AREGTYPE} should be silently recognized as a regular file.
+New archives should be created using @code{REGTYPE}. Also, for
+backward compatibility, @code{tar} treats a regular file whose name
+ends with a slash as a directory.
+
+@item @code{LNKTYPE}
+This flag represents a file linked to another file, of any type,
+previously archived. Such files are identified in Unix by each
+file having the same device and inode number. The linked-to name is
+specified in the @code{linkname} field with a trailing null.
+
+@item @code{SYMTYPE}
+This represents a symbolic link to another file. The linked-to name
+is specified in the @code{linkname} field with a trailing null.
+
+@item @code{CHRTYPE}
+@itemx @code{BLKTYPE}
+These represent character special files and block special files
+respectively. In this case the @code{devmajor} and @code{devminor}
+fields will contain the major and minor device numbers respectively.
+Operating systems may map the device specifications to their own
+local specification, or may ignore the entry.
+
+@item @code{DIRTYPE}
+This flag specifies a directory or sub-directory. The directory
+name in the @code{name} field should end with a slash. On systems where
+disk allocation is performed on a directory basis, the @code{size} field
+will contain the maximum number of bytes (which may be rounded to
+the nearest disk block allocation unit) which the directory may
+hold. A @code{size} field of zero indicates no such limiting. Systems
+which do not support limiting in this manner should ignore the
+@code{size} field.
+
+@item @code{FIFOTYPE}
+This specifies a FIFO special file. Note that the archiving of a
+FIFO file archives the existence of this file and not its contents.
+
+@item @code{CONTTYPE}
+This specifies a contiguous file, which is the same as a normal
+file except that, in operating systems which support it, all its
+space is allocated contiguously on the disk. Operating systems
+which do not allow contiguous allocation should silently treat this
+type as a normal file.
+
+@item @code{A} @dots{} @code{Z}
+These are reserved for custom implementations. Some of these are
+used in the GNU modified format, as described below.
+
+@end table
+
+Other values are reserved for specification in future revisions of
+the P1003 standard, and should not be used by any @code{tar} program.
+
+The @code{magic} field indicates that this archive was output in
+the P1003 archive format. If this field contains @code{TMAGIC},
+the @code{uname} and @code{gname} fields will contain the ASCII
+representation of the owner and group of the file respectively.
+If found, the user and group IDs are used rather than the values in
+the @code{uid} and @code{gid} fields.
+
+For references, see ISO/IEC 9945-1:1990 or IEEE Std 1003.1-1990, pages
+169-173 (section 10.1) for @cite{Archive/Interchange File Format}; and
+IEEE Std 1003.2-1992, pages 380-388 (section 4.48) and pages 936-940
+(section E.4.48) for @cite{pax - Portable archive interchange}.
+
+@node Extensions, cpio, Standard, Formats
+@section GNU Extensions to the Archive Format
+@UNREVISED
+
+The GNU format uses additional file types to describe new types of
+files in an archive. These are listed below.
+
+@table @code
+@item GNUTYPE_DUMPDIR
+@itemx 'D'
+This represents a directory and a list of files created by the
+@value{op-incremental} option. The @code{size} field gives the total
+size of the associated list of files. Each file name is preceded by
+either a @samp{Y} (the file should be in this archive) or an @samp{N}.
+(The file is a directory, or is not stored in the archive.) Each file
+name is terminated by a null. There is an additional null after the
+last file name.
+
+@item GNUTYPE_MULTIVOL
+@itemx 'M'
+This represents a file continued from another volume of a multi-volume
+archive created with the @value{op-multi-volume} option. The original
+type of the file is not given here. The @code{size} field gives the
+maximum size of this piece of the file (assuming the volume does
+not end before the file is written out). The @code{offset} field
+gives the offset from the beginning of the file where this part of
+the file begins. Thus @code{size} plus @code{offset} should equal
+the original size of the file.
+
+@item GNUTYPE_SPARSE
+@itemx 'S'
+This flag indicates that we are dealing with a sparse file. Note
+that archiving a sparse file requires special operations to find
+holes in the file, which mark the positions of these holes, along
+with the number of bytes of data to be found after the hole.
+
+@item GNUTYPE_VOLHDR
+@itemx 'V'
+This file type is used to mark the volume header that was given with
+the @value{op-label} option when the archive was created. The @code{name}
+field contains the @code{name} given after the @value{op-label} option.
+The @code{size} field is zero. Only the first file in each volume
+of an archive should have this type.
+
+@end table
+
+You may have trouble reading a GNU format archive on a non-GNU
+system if the options @value{op-incremental}, @value{op-multi-volume},
+@value{op-sparse}, or @value{op-label} were used when writing the archive.
+In general, if @code{tar} does not use the GNU-added fields of the
+header, other versions of @code{tar} should be able to read the
+archive. Otherwise, the @code{tar} program will give an error, the
+most likely one being a checksum error.
+
+@node cpio, , Extensions, Formats
+@section Comparison of @code{tar} and @code{cpio}
+@UNREVISED
+
+@FIXME{Reorganize the following material}
+
+The @code{cpio} archive formats, like @code{tar}, do have maximum
+pathname lengths. The binary and old ASCII formats have a max path
+length of 256, and the new ASCII and CRC ASCII formats have a max
+path length of 1024. GNU @code{cpio} can read and write archives
+with arbitrary pathname lengths, but other @code{cpio} implementations
+may crash unexplainedly trying to read them.
+
+@code{tar} handles symbolic links in the form in which it comes in BSD;
+@code{cpio} doesn't handle symbolic links in the form in which it comes
+in System V prior to SVR4, and some vendors may have added symlinks
+to their system without enhancing @code{cpio} to know about them.
+Others may have enhanced it in a way other than the way I did it
+at Sun, and which was adopted by AT&T (and which is, I think, also
+present in the @code{cpio} that Berkeley picked up from AT&T and put
+into a later BSD release---I think I gave them my changes).
+
+(SVR4 does some funny stuff with @code{tar}; basically, its @code{cpio}
+can handle @code{tar} format input, and write it on output, and it
+probably handles symbolic links. They may not have bothered doing
+anything to enhance @code{tar} as a result.)
+
+@code{cpio} handles special files; traditional @code{tar} doesn't.
+
+@code{tar} comes with V7, System III, System V, and BSD source;
+@code{cpio} comes only with System III, System V, and later BSD
+(4.3-tahoe and later).
+
+@code{tar}'s way of handling multiple hard links to a file can handle
+file systems that support 32-bit inumbers (e.g., the BSD file system);
+@code{cpio}s way requires you to play some games (in its "binary"
+format, i-numbers are only 16 bits, and in its "portable ASCII" format,
+they're 18 bits---it would have to play games with the "file system ID"
+field of the header to make sure that the file system ID/i-number pairs
+of different files were always different), and I don't know which
+@code{cpio}s, if any, play those games. Those that don't might get
+confused and think two files are the same file when they're not, and
+make hard links between them.
+
+@code{tar}s way of handling multiple hard links to a file places only
+one copy of the link on the tape, but the name attached to that copy
+is the @emph{only} one you can use to retrieve the file; @code{cpio}s
+way puts one copy for every link, but you can retrieve it using any
+of the names.
+
+@quotation
+What type of check sum (if any) is used, and how is this calculated.
+@end quotation
+
+See the attached manual pages for @code{tar} and @code{cpio} format.
+@code{tar} uses a checksum which is the sum of all the bytes in the
+@code{tar} header for a file; @code{cpio} uses no checksum.
+
+@quotation
+If anyone knows why @code{cpio} was made when @code{tar} was present
+at the unix scene,
+@end quotation
+
+It wasn't. @code{cpio} first showed up in PWB/UNIX 1.0; no
+generally-available version of UNIX had @code{tar} at the time. I don't
+know whether any version that was generally available @emph{within AT&T}
+had @code{tar}, or, if so, whether the people within AT&T who did
+@code{cpio} knew about it.
+
+On restore, if there is a corruption on a tape @code{tar} will stop at
+that point, while @code{cpio} will skip over it and try to restore the
+rest of the files.
+
+The main difference is just in the command syntax and header format.
+
+@code{tar} is a little more tape-oriented in that everything is blocked
+to start on a record boundary.
+
+@quotation
+Is there any differences between the ability to recover crashed
+archives between the two of them. (Is there any chance of recovering
+crashed archives at all.)
+@end quotation
+
+Theoretically it should be easier under @code{tar} since the blocking
+lets you find a header with some variation of @samp{dd skip=@var{nn}}.
+However, modern @code{cpio}'s and variations have an option to just
+search for the next file header after an error with a reasonable chance
+of re-syncing. However, lots of tape driver software won't allow you to
+continue past a media error which should be the only reason for getting
+out of sync unless a file changed sizes while you were writing the
+archive.
+
+@quotation
+If anyone knows why @code{cpio} was made when @code{tar} was present
+at the unix scene, please tell me about this too.
+@end quotation
+
+Probably because it is more media efficient (by not blocking everything
+and using only the space needed for the headers where @code{tar}
+always uses 512 bytes per file header) and it knows how to archive
+special files.
+
+You might want to look at the freely available alternatives. The major
+ones are @code{afio}, GNU @code{tar}, and @code{pax}, each of which
+have their own extensions with some backwards compatibility.
+
+Sparse files were @code{tar}red as sparse files (which you can easily
+test, because the resulting archive gets smaller, and GNU @code{cpio}
+can no longer read it).
+
+@node Media, Index, Formats, Top
+@chapter Tapes and Other Archive Media
+@UNREVISED
+
+A few special cases about tape handling warrant more detailed
+description. These special cases are discussed below.
+
+Many complexities surround the use of @code{tar} on tape drives. Since
+the creation and manipulation of archives located on magnetic tape was
+the original purpose of @code{tar}, it contains many features making
+such manipulation easier.
+
+Archives are usually written on dismountable media---tape cartridges,
+mag tapes, or floppy disks.
+
+The amount of data a tape or disk holds depends not only on its size,
+but also on how it is formatted. A 2400 foot long reel of mag tape
+holds 40 megabytes of data when formated at 1600 bits per inch. The
+physically smaller EXABYTE tape cartridge holds 2.3 gigabytes.
+
+Magnetic media are re-usable---once the archive on a tape is no longer
+needed, the archive can be erased and the tape or disk used over.
+Media quality does deteriorate with use, however. Most tapes or disks
+should be disgarded when they begin to produce data errors. EXABYTE
+tape cartridges should be disgarded when they generate an @dfn{error
+count} (number of non-usable bits) of more than 10k.
+
+Magnetic media are written and erased using magnetic fields, and
+should be protected from such fields to avoid damage to stored data.
+Sticking a floppy disk to a filing cabinet using a magnet is probably
+not a good idea.
+
+@menu
+* Device:: Device selection and switching
+* Remote Tape Server::
+* Common Problems and Solutions::
+* Blocking:: Blocking
+* Many:: Many archives on one tape
+* Using Multiple Tapes:: Using Multiple Tapes
+* label:: Including a Label in the Archive
+* verify::
+* Write Protection::
+@end menu
+
+@node Device, Remote Tape Server, Media, Media
+@section Device Selection and Switching
+@UNREVISED
+
+@table @kbd
+@item -f [@var{hostname}:]@var{file}
+@itemx --file=[@var{hostname}:]@var{file}
+Use archive file or device @var{file} on @var{hostname}.
+@end table
+
+This option is used to specify the file name of the archive @code{tar}
+works on.
+
+If the file name is @samp{-}, @code{tar} reads the archive from standard
+input (when listing or extracting), or writes it to standard output
+(when creating). If the @samp{-} file name is given when updating an
+archive, @code{tar} will read the original archive from its standard
+input, and will write the entire new archive to its standard output.
+
+If the file name contains a @samp{:}, it is interpreted as
+@samp{hostname:file name}. If the @var{hostname} contains an @dfn{at}
+sign (@kbd{@@}), it is treated as @samp{user@@hostname:file name}. In
+either case, @code{tar} will invoke the command @code{rsh} (or
+@code{remsh}) to start up an @file{/etc/rmt} on the remote machine. If
+you give an alternate login name, it will be given to the @code{rsh}.
+Naturally, the remote machine must have an executable @file{/etc/rmt}.
+This program is free software from the University of California, and a
+copy of the source code can be found with the sources for @code{tar};
+it's compiled and installed by default.
+
+If this option is not given, but the environment variable @code{TAPE} is
+set, its value is used; otherwise, old versions of @code{tar} used a default
+archive name (which was picked when @code{tar} was compiled). The
+default is normally set up to be the @dfn{first} tape drive or other
+transportable I/O medium on the system.
+
+Starting with version 1.11.5, GNU @code{tar} uses standard input and
+standard output as the default device, and I will not try anymore
+supporting automatic device detection at installation time. This was
+failing really in too many cases, it was hopeless. This is now
+completely left to the installer to override standard input and standard
+output for default device, if this seems preferrable to him/her.
+Further, I think @emph{most} actual usages of @code{tar} are done with
+pipes or disks, not really tapes, cartridges or diskettes.
+
+Some users think that using standard input and output is running
+after trouble. This could lead to a nasty surprise on your screen if
+you forget to specify an output file name---especially if you are going
+through a network or terminal server capable of buffering large amounts
+of output. We had so many bug reports in that area of configuring
+default tapes automatically, and so many contradicting requests, that
+we finally consider the problem to be portably intractable. We could
+of course use something like @samp{/dev/tape} as a default, but this
+is @emph{also} running after various kind of trouble, going from hung
+processes to accidental destruction of real tapes. After having seen
+all this mess, using standard input and output as a default really
+sounds like the only clean choice left, and a very useful one too.
+
+GNU @code{tar} reads and writes archive in records, I suspect this is the
+main reason why block devices are preferred over character devices.
+Most probably, block devices are more efficient too. The installer
+could also check for @samp{DEFTAPE} in @file{<sys/mtio.h>}.
+
+@table @kbd
+@item --force-local
+Archive file is local even if it contains a colon.
+
+@item --rsh-command=@var{command}
+Use remote @var{command} instead of @code{rsh}. This option exists
+so that people who use something other than the standard @code{rsh}
+(e.g., a Kerberized @code{rsh}) can access a remote device.
+
+When this command is not used, the shell command found when
+the @code{tar} program was installed is used instead. This is
+the first found of @file{/usr/ucb/rsh}, @file{/usr/bin/remsh},
+@file{/usr/bin/rsh}, @file{/usr/bsd/rsh} or @file{/usr/bin/nsh}.
+The installer may have overriden this by defining the environment
+variable @code{RSH} @emph{at installation time}.
+
+@item -[0-7][lmh]
+Specify drive and density.
+
+@item -M
+@itemx --multi-volume
+Create/list/extract multi-volume archive.
+
+This option causes @code{tar} to write a @dfn{multi-volume} archive---one
+that may be larger than will fit on the medium used to hold it.
+@xref{Multi-Volume Archives}.
+
+@item -L @var{num}
+@itemx --tape-length=@var{num}
+Change tape after writing @var{num} x 1024 bytes.
+
+This option might be useful when your tape drivers do not properly
+detect end of physical tapes. By being slightly conservative on the
+maximum tape length, you might avoid the problem entirely.
+
+@item -F @var{file}
+@itemx --info-script=@var{file}
+@itemx --new-volume-script=@var{file}
+Execute @file{file} at end of each tape. This implies
+@value{op-multi-volume}.
+@end table
+
+@node Remote Tape Server, Common Problems and Solutions, Device, Media
+@section The Remote Tape Server
+
+@cindex remote tape drive
+@pindex rmt
+In order to access the tape drive on a remote machine, @code{tar}
+uses the remote tape server written at the University of California at
+Berkeley. The remote tape server must be installed as @file{/etc/rmt}
+on any machine whose tape drive you want to use. @code{tar} calls
+@file{/etc/rmt} by running an @code{rsh} or @code{remsh} to the remote
+machine, optionally using a different login name if one is supplied.
+
+A copy of the source for the remote tape server is provided. It is
+Copyright @copyright{} 1983 by the Regents of the University of
+California, but can be freely distributed. Instructions for compiling
+and installing it are included in the @file{Makefile}.
+
+@cindex absolute file names
+Unless you use the @value{op-absolute-names} option, GNU @code{tar} will
+not allow you to create an archive that contains absolute file names
+(a file name beginning with @samp{/}.) If you try, @code{tar} will
+automatically remove the leading @samp{/} from the file names it
+stores in the archive. It will also type a warning message telling
+you what it is doing.
+
+When reading an archive that was created with a different @code{tar}
+program, GNU @code{tar} automatically extracts entries in the archive
+which have absolute file names as if the file names were not absolute.
+This is an important feature. A visitor here once gave a
+@code{tar} tape to an operator to restore; the operator used Sun @code{tar}
+instead of GNU @code{tar}, and the result was that it replaced large
+portions of our @file{/bin} and friends with versions from the tape;
+needless to say, we were unhappy about having to recover the file system
+from backup tapes.
+
+For example, if the archive contained a file @file{/usr/bin/computoy},
+GNU @code{tar} would extract the file to @file{usr/bin/computoy},
+relative to the current directory. If you want to extract the files in
+an archive to the same absolute names that they had when the archive
+was created, you should do a @samp{cd /} before extracting the files
+from the archive, or you should either use the @value{op-absolute-names}
+option, or use the command @samp{tar -C / @dots{}}.
+
+@cindex Ultrix 3.1 and write failure
+Some versions of Unix (Ultrix 3.1 is know to have this problem),
+can claim that a short write near the end of a tape succeeded,
+when it actually failed. This will result in the -M option not
+working correctly. The best workaround at the moment is to use a
+significantly larger blocking factor than the default 20.
+
+In order to update an archive, @code{tar} must be able to backspace the
+archive in order to reread or rewrite a record that was just read (or
+written). This is currently possible only on two kinds of files: normal
+disk files (or any other file that can be backspaced with @samp{lseek}),
+and industry-standard 9-track magnetic tape (or any other kind of tape
+that can be backspaced with the @code{MTIOCTOP} @code{ioctl}.
+
+This means that the @value{op-append}, @value{op-update},
+@value{op-concatenate}, and @value{op-delete} commands will not work on any
+other kind of file. Some media simply cannot be backspaced, which
+means these commands and options will never be able to work on them.
+These non-backspacing media include pipes and cartridge tape drives.
+
+Some other media can be backspaced, and @code{tar} will work on them
+once @code{tar} is modified to do so.
+
+Archives created with the @value{op-multi-volume}, @value{op-label}, and
+@value{op-incremental} options may not be readable by other version
+of @code{tar}. In particular, restoring a file that was split over
+a volume boundary will require some careful work with @code{dd}, if
+it can be done at all. Other versions of @code{tar} may also create
+an empty file whose name is that of the volume header. Some versions
+of @code{tar} may create normal files instead of directories archived
+with the @value{op-incremental} option.
+
+@node Common Problems and Solutions, Blocking, Remote Tape Server, Media
+@section Some Common Problems and their Solutions
+
+@ifclear PUBLISH
+
+@format
+errors from system:
+permission denied
+no such file or directory
+not owner
+
+errors from @code{tar}:
+directory checksum error
+header format error
+
+errors from media/system:
+i/o error
+device busy
+@end format
+
+@end ifclear
+
+@node Blocking, Many, Common Problems and Solutions, Media
+@section Blocking
+@UNREVISED
+
+@dfn{Block} and @dfn{record} terminology is rather confused, and it
+is also confusing to the expert reader. On the other hand, readers
+who are new to the field have a fresh mind, and they may safely skip
+the next two paragraphs, as the remainder of this manual uses those
+two terms in a quite consistent way.
+
+John Gilmore, the writer of the public domain @code{tar} from which
+GNU @code{tar} was originally derived, wrote (June 1995):
+
+@quotation
+The nomenclature of tape drives comes from IBM, where I believe
+they were invented for the IBM 650 or so. On IBM mainframes, what
+is recorded on tape are tape blocks. The logical organization of
+data is into records. There are various ways of putting records into
+blocks, including @code{F} (fixed sized records), @code{V} (variable
+sized records), @code{FB} (fixed blocked: fixed size records, @var{n}
+to a block), @code{VB} (variable size records, @var{n} to a block),
+@code{VSB} (variable spanned blocked: variable sized records that can
+occupy more than one block), etc. The @code{JCL} @samp{DD RECFORM=}
+parameter specified this to the operating system.
+
+The Unix man page on @code{tar} was totally confused about this.
+When I wrote @code{PD TAR}, I used the historically correct terminology
+(@code{tar} writes data records, which are grouped into blocks).
+It appears that the bogus terminology made it into POSIX (no surprise
+here), and now Fran@,{c}ois has migrated that terminology back
+into the source code too.
+@end quotation
+
+The term @dfn{physical block} means the basic transfer chunk from or
+to a device, after which reading or writing may stop without anything
+being lost. In this manual, the term @dfn{block} usually refers to
+a disk physical block, @emph{assuming} that each disk block is 512
+bytes in length. It is true that some disk devices have different
+physical blocks, but @code{tar} ignore these differences in its own
+format, which is meant to be portable, so a @code{tar} block is always
+512 bytes in length, and @dfn{block} always mean a @code{tar} block.
+The term @dfn{logical block} often represents the basic chunk of
+allocation of many disk blocks as a single entity, which the operating
+system treats somewhat atomically; this concept is only barely used
+in GNU @code{tar}.
+
+The term @dfn{physical record} is another way to speak of a physical
+block, those two terms are somewhat interchangeable. In this manual,
+the term @dfn{record} usually refers to a tape physical block,
+@emph{assuming} that the @code{tar} archive is kept on magnetic tape.
+It is true that archives may be put on disk or used with pipes,
+but nevertheless, @code{tar} tries to read and write the archive one
+@dfn{record} at a time, whatever the medium in use. One record is made
+up of an integral number of blocks, and this operation of putting many
+disk blocks into a single tape block is called @dfn{reblocking}, or
+more simply, @dfn{blocking}. The term @dfn{logical record} refers to
+the logical organization of many characters into something meaningful
+to the application. The term @dfn{unit record} describes a small set
+of characters which are transmitted whole to or by the application,
+and often refers to a line of text. Those two last terms are unrelated
+to what we call a @dfn{record} in GNU @code{tar}.
+
+When writing to tapes, @code{tar} writes the contents of the archive
+in chunks known as @dfn{records}. To change the default blocking
+factor, use the @value{op-blocking-factor} option. Each record will
+then be composed of @var{512-size} blocks. (Each @code{tar} block is
+512 bytes. @xref{Standard}.) Each file written to the archive uses
+at least one full record. As a result, using a larger record size
+can result in more wasted space for small files. On the other hand, a
+larger record size can often be read and written much more efficiently.
+
+Further complicating the problem is that some tape drives ignore the
+blocking entirely. For these, a larger record size can still improve
+performance (because the software layers above the tape drive still
+honor the blocking), but not as dramatically as on tape drives that
+honor blocking.
+
+When reading an archive, @code{tar} can usually figure out the record
+size on itself. When this is the case, and a non-standard record size
+was used when the archive was created, @code{tar} will print a message
+about a non-standard blocking factor, and then operate normally. On
+some tape devices, however, @code{tar} cannot figure out the record size
+itself. On most of those, you can specify a blocking factor (with
+@value{op-blocking-factor}) larger than the actual blocking factor, and then use
+the @value{op-read-full-records} option. (If you specify a blocking factor
+with @value{op-blocking-factor} and don't use the @value{op-read-full-records}
+option, then @code{tar} will not attempt to figure out the recording size
+itself.) On some devices, you must always specify the record size
+exactly with @value{op-blocking-factor} when reading, because @code{tar} cannot
+figure it out. In any case, use @value{op-list} before doing any
+extractions to see whether @code{tar} is reading the archive correctly.
+
+@code{tar} blocks are all fixed size (512 bytes), and its scheme for
+putting them into records is to put a whole number of them (one or
+more) into each record. @code{tar} records are all the same size;
+at the end of the file there's a block containing all zeros, which
+is how you tell that the remainder of the last record(s) are garbage.
+
+In a standard @code{tar} file (no options), the block size is 512
+and the record size is 10240, for a blocking factor of 20. What the
+@value{op-blocking-factor} option does is sets the blocking factor,
+changing the record size while leaving the block size at 512 bytes.
+20 was fine for ancient 800 or 1600 bpi reel-to-reel tape drives;
+most tape drives these days prefer much bigger records in order to
+stream and not waste tape. When writing tapes for myself, some tend
+to use a factor of the order of 2048, say, giving a record size of
+around one megabyte.
+
+If you use a blocking factor larger than 20, older @code{tar} programs
+might not be able to read the archive, so we recommend this as a limit
+to use in practice. GNU @code{tar}, however, will support arbitrarily
+large record sizes, limited only by the amount of virtual memory or the
+physical characteristics of the tape device.
+
+@menu
+* Format Variations:: Format Variations
+* Blocking Factor:: The Blocking Factor of an Archive
+@end menu
+
+@node Format Variations, Blocking Factor, Blocking, Blocking
+@subsection Format Variations
+@cindex Format Parameters
+@cindex Format Options
+@cindex Options, archive format specifying
+@cindex Options, format specifying
+@UNREVISED
+
+Format parameters specify how an archive is written on the archive
+media. The best choice of format parameters will vary depending on
+the type and number of files being archived, and on the media used to
+store the archive.
+
+To specify format parameters when accessing or creating an archive,
+you can use the options described in the following sections.
+If you do not specify any format parameters, @code{tar} uses
+default parameters. You cannot modify a compressed archive.
+If you create an archive with the @value{op-blocking-factor} option
+specified (@value{pxref-blocking-factor}), you must specify that
+blocking-factor when operating on the archive. @xref{Formats}, for other
+examples of format parameter considerations.
+
+@node Blocking Factor, , Format Variations, Blocking
+@subsection The Blocking Factor of an Archive
+@cindex Blocking Factor
+@cindex Record Size
+@cindex Number of blocks per record
+@cindex Number of bytes per record
+@cindex Bytes per record
+@cindex Blocks per record
+@UNREVISED
+
+The data in an archive is grouped into blocks, which are 512 bytes.
+Blocks are read and written in whole number multiples called
+@dfn{records}. The number of blocks in a record (ie. the size of a
+record in units of 512 bytes) is called the @dfn{blocking factor}.
+The @value{op-blocking-factor} option specifies the blocking factor of
+an archive. The default blocking factor is typically 20 (ie.@:
+10240 bytes), but can be specified at installation. To find out
+the blocking factor of an existing archive, use @samp{tar --list
+--file=@var{archive-name}}. This may not work on some devices.
+
+Records are separated by gaps, which waste space on the archive media.
+If you are archiving on magnetic tape, using a larger blocking factor
+(and therefore larger records) provides faster throughput and allows you
+to fit more data on a tape (because there are fewer gaps). If you are
+archiving on cartridge, a very large blocking factor (say 126 or more)
+greatly increases performance. A smaller blocking factor, on the other
+hand, may be usefull when archiving small files, to avoid archiving lots
+of nulls as @code{tar} fills out the archive to the end of the record.
+In general, the ideal record size depends on the size of the
+inter-record gaps on the tape you are using, and the average size of the
+files you are archiving. @xref{create}, for information on
+writing archives.
+
+@FIXME{Need example of using a cartridge with blocking factor=126 or more.}
+
+Archives with blocking factors larger than 20 cannot be read
+by very old versions of @code{tar}, or by some newer versions
+of @code{tar} running on old machines with small address spaces.
+With GNU @code{tar}, the blocking factor of an archive is limited
+only by the maximum record size of the device containing the archive,
+or by the amount of available virtual memory.
+
+Also, on some systems, not using adequate blocking factors, as sometimes
+imposed by the device drivers, may yield unexpected diagnostics. For
+example, this has been reported:
+
+@example
+Cannot write to /dev/dlt: Invalid argument
+@end example
+
+@noindent
+In such cases, it sometimes happen that the @code{tar} bundled by the
+system is aware of block size idiosyncrasies, while GNU @code{tar} requires
+an explicit specification for the block size, which it cannot guess.
+This yields some people to consider GNU @code{tar} is misbehaving, because
+by comparison, @cite{the bundle @code{tar} works OK}. Adding @w{@kbd{-b
+256}}, for example, might resolve the problem.
+
+If you use a non-default blocking factor when you create an archive, you
+must specify the same blocking factor when you modify that archive. Some
+archive devices will also require you to specify the blocking factor when
+reading that archive, however this is not typically the case. Usually, you
+can use @value{op-list} without specifying a blocking factor---@code{tar}
+reports a non-default record size and then lists the archive members as
+it would normally. To extract files from an archive with a non-standard
+blocking factor (particularly if you're not sure what the blocking factor
+is), you can usually use the @value{op-read-full-records} option while
+specifying a blocking factor larger then the blocking factor of the archive
+(ie. @samp{tar --extract --read-full-records --blocking-factor=300}.
+@xref{list}, for more information on the @value{op-list}
+operation. @xref{Reading}, for a more detailed explanation of that option.
+
+@table @kbd
+@item --blocking-factor=@var{number}
+@itemx -b @var{number}
+Specifies the blocking factor of an archive. Can be used with any
+operation, but is usually not necessary with @value{op-list}.
+@end table
+
+Device blocking
+
+@table @kbd
+@item -b @var{blocks}
+@itemx --blocking-factor=@var{blocks}
+Set record size to @math{@var{blocks} * 512} bytes.
+
+This option is used to specify a @dfn{blocking factor} for the archive.
+When reading or writing the archive, @code{tar}, will do reads and writes
+of the archive in records of @math{@var{block}*512} bytes. This is true
+even when the archive is compressed. Some devices requires that all
+write operations be a multiple of a certain size, and so, @code{tar}
+pads the archive out to the next record boundary.
+
+The default blocking factor is set when @code{tar} is compiled, and is
+typically 20. Blocking factors larger than 20 cannot be read by very
+old versions of @code{tar}, or by some newer versions of @code{tar}
+running on old machines with small address spaces.
+
+With a magnetic tape, larger records give faster throughput and fit
+more data on a tape (because there are fewer inter-record gaps).
+If the archive is in a disk file or a pipe, you may want to specify
+a smaller blocking factor, since a large one will result in a large
+number of null bytes at the end of the archive.
+
+When writing cartridge or other streaming tapes, a much larger
+blocking factor (say 126 or more) will greatly increase performance.
+However, you must specify the same blocking factor when reading or
+updating the archive.
+
+Apparently, Exabyte drives have a physical block size of 8K bytes.
+If we choose our blocksize as a multiple of 8k bytes, then the problem
+seems to dissapper. Id est, we are using block size of 112 right
+now, and we haven't had the problem since we switched@dots{}
+
+With GNU @code{tar} the blocking factor is limited only by the maximum
+record size of the device containing the archive, or by the amount of
+available virtual memory.
+
+However, deblocking or reblocking is virtually avoided in a special
+case which often occurs in practice, but which requires all the
+following conditions to be simultaneously true:
+@itemize @bullet
+@item
+the archive is subject to a compression option,
+@item
+the archive is not handled through standard input or output, nor
+redirected nor piped,
+@item
+the archive is directly handled to a local disk, instead of any special
+device,
+@item
+@value{op-blocking-factor} is not explicitely specified on the @code{tar}
+invocation.
+@end itemize
+
+In previous versions of GNU @code{tar}, the @samp{--compress-block}
+option (or even older: @samp{--block-compress}) was necessary to
+reblock compressed archives. It is now a dummy option just asking
+not to be used, and otherwise ignored. If the output goes directly
+to a local disk, and not through stdout, then the last write is
+not extended to a full record size. Otherwise, reblocking occurs.
+Here are a few other remarks on this topic:
+
+@itemize @bullet
+
+@item
+@code{gzip} will complain about trailing garbage if asked to
+uncompress a compressed archive on tape, there is an option to turn
+the message off, but it breaks the regularity of simply having to use
+@samp{@var{prog} -d} for decompression. It would be nice if gzip was
+silently ignoring any number of trailing zeros. I'll ask Jean-loup
+Gailly, by sending a copy of this message to him.
+
+@item
+@code{compress} does not show this problem, but as Jean-loup pointed
+out to Michael, @samp{compress -d} silently adds garbage after
+the result of decompression, which tar ignores because it already
+recognized its end-of-file indicator. So this bug may be safely
+ignored.
+
+@item
+@samp{gzip -d -q} will be silent about the trailing zeros indeed,
+but will still return an exit status of 2 which tar reports in turn.
+@code{tar} might ignore the exit status returned, but I hate doing
+that, as it weakens the protection @code{tar} offers users against
+other possible problems at decompression time. If @code{gzip} was
+silently skipping trailing zeros @emph{and} also avoiding setting the
+exit status in this innocuous case, that would solve this situation.
+
+@item
+@code{tar} should become more solid at not stopping to read a pipe at
+the first null block encountered. This inelegantly breaks the pipe.
+@code{tar} should rather drain the pipe out before exiting itself.
+@end itemize
+
+@item -i
+@itemx --ignore-zeros
+Ignore blocks of zeros in archive (means EOF).
+
+The @value{op-ignore-zeros} option causes @code{tar} to ignore blocks
+of zeros in the archive. Normally a block of zeros indicates the
+end of the archive, but when reading a damaged archive, or one which
+was created by @code{cat}-ing several archives together, this option
+allows @code{tar} to read the entire archive. This option is not on
+by default because many versions of @code{tar} write garbage after
+the zeroed blocks.
+
+Note that this option causes @code{tar} to read to the end of the
+archive file, which may sometimes avoid problems when multiple files
+are stored on a single physical tape.
+
+@item -B
+@itemx --read-full-records
+Reblock as we read (for reading 4.2BSD pipes).
+
+If @value{op-read-full-records} is used, @code{tar} will not panic if an
+attempt to read a record from the archive does not return a full record.
+Instead, @code{tar} will keep reading until it has obtained a full
+record.
+
+This option is turned on by default when @code{tar} is reading
+an archive from standard input, or from a remote machine. This is
+because on BSD Unix systems, a read of a pipe will return however
+much happens to be in the pipe, even if it is less than @code{tar}
+requested. If this option was not used, @code{tar} would fail as
+soon as it read an incomplete record from the pipe.
+
+This option is also useful with the commands for updating an archive.
+
+@end table
+
+Tape blocking
+
+@FIXME{Appropriate options should be moved here from elsewhere.}
+
+@cindex blocking factor
+@cindex tape blocking
+
+When handling various tapes or cartridges, you have to take care of
+selecting a proper blocking, that is, the number of disk blocks you
+put together as a single tape block on the tape, without intervening
+tape gaps. A @dfn{tape gap} is a small landing area on the tape
+with no information on it, used for decelerating the tape to a
+full stop, and for later regaining the reading or writing speed.
+When the tape driver starts reading a record, the record has to
+be read whole without stopping, as a tape gap is needed to stop the
+tape motion without loosing information.
+
+@cindex Exabyte blocking
+@cindex DAT blocking
+Using higher blocking (putting more disk blocks per tape block) will use
+the tape more efficiently as there will be less tape gaps. But reading
+such tapes may be more difficult for the system, as more memory will be
+required to receive at once the whole record. Further, if there is a
+reading error on a huge record, this is less likely that the system will
+succeed in recovering the information. So, blocking should not be too
+low, nor it should be too high. @code{tar} uses by default a blocking of
+20 for historical reasons, and it does not really matter when reading or
+writing to disk. Current tape technology would easily accomodate higher
+blockings. Sun recommends a blocking of 126 for Exabytes and 96 for DATs.
+We were told that for some DLT drives, the blocking should be a multiple
+of 4Kb, preferably 64Kb (@w{@kbd{-b 128}}) or 256 for decent performance.
+Other manufacturers may use different recommendations for the same tapes.
+This might also depends of the buffering techniques used inside modern
+tape controllers. Some imposes a minimum blocking, or a maximum blocking.
+Others request blocking to be some exponent of two.
+
+So, there is no fixed rule for blocking. But blocking at read time
+should ideally be the same as blocking used at write time. At one place
+I know, with a wide variety of equipment, they found it best to use a
+blocking of 32 to guarantee that their tapes are fully interchangeable.
+
+I was also told that, for recycled tapes, prior erasure (by the same
+drive unit that will be used to create the archives) sometimes lowers
+the error rates observed at rewriting time.
+
+I might also use @samp{--number-blocks} instead of
+@samp{--block-number}, so @samp{--block} will then expand to
+@samp{--blocking-factor} unambiguously.
+
+@node Many, Using Multiple Tapes, Blocking, Media
+@section Many Archives on One Tape
+
+@FIXME{Appropriate options should be moved here from elsewhere.}
+
+@findex ntape @r{device}
+Most tape devices have two entries in the @file{/dev} directory, or
+entries that come in pairs, which differ only in the minor number for
+this device. Let's take for example @file{/dev/tape}, which often
+points to the only or usual tape device of a given system. There might
+be a corresponding @file{/dev/nrtape} or @file{/dev/ntape}. The simpler
+name is the @emph{rewinding} version of the device, while the name
+having @samp{nr} in it is the @emph{no rewinding} version of the same
+device.
+
+A rewinding tape device will bring back the tape to its beginning point
+automatically when this device is opened or closed. Since @code{tar}
+opens the archive file before using it and closes it afterwards, this
+means that a simple:
+
+@example
+$ @kbd{tar cf /dev/tape @var{directory}}
+@end example
+
+@noindent
+will reposition the tape to its beginning both prior and after saving
+@var{directory} contents to it, thus erasing prior tape contents and
+making it so that any subsequent write operation will destroy what has
+just been saved.
+
+@cindex tape positioning
+So, a rewinding device is normally meant to hold one and only one file.
+If you want to put more than one @code{tar} archive on a given tape, you
+will need to avoid using the rewinding version of the tape device. You
+will also have to pay special attention to tape positioning. Errors in
+positionning may overwrite the valuable data already on your tape. Many
+people, burnt by past experiences, will only use rewinding devices and
+limit themselves to one file per tape, precisely to avoid the risk of
+such errors. Be fully aware that writing at the wrong position on a
+tape loses all information past this point and most probably until the
+end of the tape, and this destroyed information @emph{cannot} be
+recovered.
+
+To save @var{directory-1} as a first archive at the beginning of a
+tape, and leave that tape ready for a second archive, you should use: