Rebase libarchive to 2.8.0

1 files changed, 805 insertions, 0 deletions

diff --git a/libarchive/libarchive-2.8.0/doc/wiki/ManPageTar5.wiki b/libarchive/libarchive-2.8.0/doc/wiki/ManPageTar5.wiki
new file mode 100644
index 0000000..12fd514
--- /dev/null
+++ b/libarchive/libarchive-2.8.0/doc/wiki/ManPageTar5.wiki
@@ -0,0 +1,805 @@
+#summary tar 5 manual page
+== NAME ==
+*tar*
+- format of tape archive files
+== DESCRIPTION ==
+The
+*tar*
+archive format collects any number of files, directories, and other
+file system objects (symbolic links, device nodes, etc.) into a single
+stream of bytes.
+The format was originally designed to be used with
+tape drives that operate with fixed-size blocks, but is widely used as
+a general packaging mechanism.
+=== General Format===
+A
+*tar*
+archive consists of a series of 512-byte records.
+Each file system object requires a header record which stores basic metadata
+(pathname, owner, permissions, etc.) and zero or more records containing any
+file data.
+The end of the archive is indicated by two records consisting
+entirely of zero bytes.
+
+For compatibility with tape drives that use fixed block sizes,
+programs that read or write tar files always read or write a fixed
+number of records with each I/O operation.
+These
+"blocks"
+are always a multiple of the record size.
+The maximum block size supported by early
+implementations was 10240 bytes or 20 records.
+This is still the default for most implementations
+although block sizes of 1MiB (2048 records) or larger are
+commonly used with modern high-speed tape drives.
+(Note: the terms
+"block"
+and
+"record"
+here are not entirely standard; this document follows the
+convention established by John Gilmore in documenting
+*pdtar*.)
+=== Old-Style Archive Format===
+The original tar archive format has been extended many times to
+include additional information that various implementors found
+necessary.
+This section describes the variant implemented by the tar command
+included in
+At v7,
+which seems to be the earliest widely-used version of the tar program.
+
+The header record for an old-style
+*tar*
+archive consists of the following:
+{{{
+struct header_old_tar {
+	char name[100];
+	char mode[8];
+	char uid[8];
+	char gid[8];
+	char size[12];
+	char mtime[12];
+	char checksum[8];
+	char linkflag[1];
+	char linkname[100];
+	char pad[255];
+};
+}}}
+All unused bytes in the header record are filled with nulls.
+<dl>
+<dt>_name_</dt><dd>
+Pathname, stored as a null-terminated string.
+Early tar implementations only stored regular files (including
+hardlinks to those files).
+One common early convention used a trailing "/" character to indicate
+a directory name, allowing directory permissions and owner information
+to be archived and restored.
+</dd><dt>_mode_</dt><dd>
+File mode, stored as an octal number in ASCII.
+</dd><dt>_uid_, _gid_</dt><dd>
+User id and group id of owner, as octal numbers in ASCII.
+</dd><dt>_size_</dt><dd>
+Size of file, as octal number in ASCII.
+For regular files only, this indicates the amount of data
+that follows the header.
+In particular, this field was ignored by early tar implementations
+when extracting hardlinks.
+Modern writers should always store a zero length for hardlink entries.
+</dd><dt>_mtime_</dt><dd>
+Modification time of file, as an octal number in ASCII.
+This indicates the number of seconds since the start of the epoch,
+00:00:00 UTC January 1, 1970.
+Note that negative values should be avoided
+here, as they are handled inconsistently.
+</dd><dt>_checksum_</dt><dd>
+Header checksum, stored as an octal number in ASCII.
+To compute the checksum, set the checksum field to all spaces,
+then sum all bytes in the header using unsigned arithmetic.
+This field should be stored as six octal digits followed by a null and a space
+character.
+Note that many early implementations of tar used signed arithmetic
+for the checksum field, which can cause interoperability problems
+when transferring archives between systems.
+Modern robust readers compute the checksum both ways and accept the
+header if either computation matches.
+</dd><dt>_linkflag_, _linkname_</dt><dd>
+In order to preserve hardlinks and conserve tape, a file
+with multiple links is only written to the archive the first
+time it is encountered.
+The next time it is encountered, the
+_linkflag_
+is set to an ASCII
+Sq 1
+and the
+_linkname_
+field holds the first name under which this file appears.
+(Note that regular files have a null value in the
+_linkflag_
+field.)
+</dd></dl>
+
+Early tar implementations varied in how they terminated these fields.
+The tar command in
+At v7
+used the following conventions (this is also documented in early BSD manpages):
+the pathname must be null-terminated;
+the mode, uid, and gid fields must end in a space and a null byte;
+the size and mtime fields must end in a space;
+the checksum is terminated by a null and a space.
+Early implementations filled the numeric fields with leading spaces.
+This seems to have been common practice until the
+IEEE Std 1003.1-1988 (``POSIX.1'')
+standard was released.
+For best portability, modern implementations should fill the numeric
+fields with leading zeros.
+=== Pre-POSIX Archives===
+An early draft of
+IEEE Std 1003.1-1988 (``POSIX.1'')
+served as the basis for John Gilmore's
+*pdtar*
+program and many system implementations from the late 1980s
+and early 1990s.
+These archives generally follow the POSIX ustar
+format described below with the following variations:
+<ul>
+<li>
+The magic value is
+"ustar\ \&"
+(note the following space).
+The version field contains a space character followed by a null.
+</li><li>
+The numeric fields are generally filled with leading spaces
+(not leading zeros as recommended in the final standard).
+</li><li>
+The prefix field is often not used, limiting pathnames to
+the 100 characters of old-style archives.
+</li></ul>
+=== POSIX ustar Archives===
+IEEE Std 1003.1-1988 (``POSIX.1'')
+defined a standard tar file format to be read and written
+by compliant implementations of
+*tar*(1).
+This format is often called the
+"ustar"
+format, after the magic value used
+in the header.
+(The name is an acronym for
+"Unix Standard TAR".)
+It extends the historic format with new fields:
+{{{
+struct header_posix_ustar {
+	char name[100];
+	char mode[8];
+	char uid[8];
+	char gid[8];
+	char size[12];
+	char mtime[12];
+	char checksum[8];
+	char typeflag[1];
+	char linkname[100];
+	char magic[6];
+	char version[2];
+	char uname[32];
+	char gname[32];
+	char devmajor[8];
+	char devminor[8];
+	char prefix[155];
+	char pad[12];
+};
+}}}
+<dl>
+<dt>_typeflag_</dt><dd>
+Type of entry.
+POSIX extended the earlier
+_linkflag_
+field with several new type values:
+<dl>
+<dt>"0"</dt><dd>
+Regular file.
+NUL should be treated as a synonym, for compatibility purposes.
+</dd><dt>"1"</dt><dd>
+Hard link.
+</dd><dt>"2"</dt><dd>
+Symbolic link.
+</dd><dt>"3"</dt><dd>
+Character device node.
+</dd><dt>"4"</dt><dd>
+Block device node.
+</dd><dt>"5"</dt><dd>
+Directory.
+</dd><dt>"6"</dt><dd>
+FIFO node.
+</dd><dt>"7"</dt><dd>
+Reserved.
+</dd><dt>Other</dt><dd>
+A POSIX-compliant implementation must treat any unrecognized typeflag value
+as a regular file.
+In particular, writers should ensure that all entries
+have a valid filename so that they can be restored by readers that do not
+support the corresponding extension.
+Uppercase letters "A" through "Z" are reserved for custom extensions.
+Note that sockets and whiteout entries are not archivable.
+</dd></dl>
+It is worth noting that the
+_size_
+field, in particular, has different meanings depending on the type.
+For regular files, of course, it indicates the amount of data
+following the header.
+For directories, it may be used to indicate the total size of all
+files in the directory, for use by operating systems that pre-allocate
+directory space.
+For all other types, it should be set to zero by writers and ignored
+by readers.
+</dd><dt>_magic_</dt><dd>
+Contains the magic value
+"ustar"
+followed by a NUL byte to indicate that this is a POSIX standard archive.
+Full compliance requires the uname and gname fields be properly set.
+</dd><dt>_version_</dt><dd>
+Version.
+This should be
+"00"
+(two copies of the ASCII digit zero) for POSIX standard archives.
+</dd><dt>_uname_, _gname_</dt><dd>
+User and group names, as null-terminated ASCII strings.
+These should be used in preference to the uid/gid values
+when they are set and the corresponding names exist on
+the system.
+</dd><dt>_devmajor_, _devminor_</dt><dd>
+Major and minor numbers for character device or block device entry.
+</dd><dt>_name_, _prefix_</dt><dd>
+If the pathname is too long to fit in the 100 bytes provided by the standard
+format, it can be split at any
+_/_
+character with the first portion going into the prefix field.
+If the prefix field is not empty, the reader will prepend
+the prefix value and a
+_/_
+character to the regular name field to obtain the full pathname.
+The standard does not require a trailing
+_/_
+character on directory names, though most implementations still
+include this for compatibility reasons.
+</dd></dl>
+
+Note that all unused bytes must be set to
+NUL.
+
+Field termination is specified slightly differently by POSIX
+than by previous implementations.
+The
+_magic_,
+_uname_,
+and
+_gname_
+fields must have a trailing
+NUL.
+The
+_pathname_,
+_linkname_,
+and
+_prefix_
+fields must have a trailing
+NUL
+unless they fill the entire field.
+(In particular, it is possible to store a 256-character pathname if it
+happens to have a
+_/_
+as the 156th character.)
+POSIX requires numeric fields to be zero-padded in the front, and requires
+them to be terminated with either space or
+NUL
+characters.
+
+Currently, most tar implementations comply with the ustar
+format, occasionally extending it by adding new fields to the
+blank area at the end of the header record.
+=== Pax Interchange Format===
+There are many attributes that cannot be portably stored in a
+POSIX ustar archive.
+IEEE Std 1003.1-2001 (``POSIX.1'')
+defined a
+"pax interchange format"
+that uses two new types of entries to hold text-formatted
+metadata that applies to following entries.
+Note that a pax interchange format archive is a ustar archive in every
+respect.
+The new data is stored in ustar-compatible archive entries that use the
+"x"
+or
+"g"
+typeflag.
+In particular, older implementations that do not fully support these
+extensions will extract the metadata into regular files, where the
+metadata can be examined as necessary.
+
+An entry in a pax interchange format archive consists of one or
+two standard ustar entries, each with its own header and data.
+The first optional entry stores the extended attributes
+for the following entry.
+This optional first entry has an "x" typeflag and a size field that
+indicates the total size of the extended attributes.
+The extended attributes themselves are stored as a series of text-format
+lines encoded in the portable UTF-8 encoding.
+Each line consists of a decimal number, a space, a key string, an equals
+sign, a value string, and a new line.
+The decimal number indicates the length of the entire line, including the
+initial length field and the trailing newline.
+An example of such a field is:
+{{{
+25 ctime=1084839148.1212\en
+}}}
+Keys in all lowercase are standard keys.
+Vendors can add their own keys by prefixing them with an all uppercase
+vendor name and a period.
+Note that, unlike the historic header, numeric values are stored using
+decimal, not octal.
+A description of some common keys follows:
+<dl>
+<dt>*atime*, *ctime*, *mtime*</dt><dd>
+File access, inode change, and modification times.
+These fields can be negative or include a decimal point and a fractional value.
+</dd><dt>*uname*, *uid*, *gname*, *gid*</dt><dd>
+User name, group name, and numeric UID and GID values.
+The user name and group name stored here are encoded in UTF8
+and can thus include non-ASCII characters.
+The UID and GID fields can be of arbitrary length.
+</dd><dt>*linkpath*</dt><dd>
+The full path of the linked-to file.
+Note that this is encoded in UTF8 and can thus include non-ASCII characters.
+</dd><dt>*path*</dt><dd>
+The full pathname of the entry.
+Note that this is encoded in UTF8 and can thus include non-ASCII characters.
+</dd><dt>*realtime.`*`*, *security.`*`*</dt><dd>
+These keys are reserved and may be used for future standardization.
+</dd><dt>*size*</dt><dd>
+The size of the file.
+Note that there is no length limit on this field, allowing conforming
+archives to store files much larger than the historic 8GB limit.
+</dd><dt>*SCHILY.`*`*</dt><dd>
+Vendor-specific attributes used by Joerg Schilling's
+*star*
+implementation.
+</dd><dt>*SCHILY.acl.access*, *SCHILY.acl.default*</dt><dd>
+Stores the access and default ACLs as textual strings in a format
+that is an extension of the format specified by POSIX.1e draft 17.
+In particular, each user or group access specification can include a fourth
+colon-separated field with the numeric UID or GID.
+This allows ACLs to be restored on systems that may not have complete
+user or group information available (such as when NIS/YP or LDAP services
+are temporarily unavailable).
+</dd><dt>*SCHILY.devminor*, *SCHILY.devmajor*</dt><dd>
+The full minor and major numbers for device nodes.
+</dd><dt>*SCHILY.fflags*</dt><dd>
+The file flags.
+</dd><dt>*SCHILY.realsize*</dt><dd>
+The full size of the file on disk.
+XXX explain? XXX
+</dd><dt>*SCHILY.dev,* *SCHILY.ino*, *SCHILY.nlinks*</dt><dd>
+The device number, inode number, and link count for the entry.
+In particular, note that a pax interchange format archive using Joerg
+Schilling's
+*SCHILY.`*`*
+extensions can store all of the data from
+_struct_ stat.
+</dd><dt>*LIBARCHIVE.xattr.*_namespace_._key_</dt><dd>
+Libarchive stores POSIX.1e-style extended attributes using
+keys of this form.
+The
+_key_
+value is URL-encoded:
+All non-ASCII characters and the two special characters
+"="
+and
+"%"
+are encoded as
+"%"
+followed by two uppercase hexadecimal digits.
+The value of this key is the extended attribute value
+encoded in base 64.
+XXX Detail the base-64 format here XXX
+</dd><dt>*VENDOR.`*`*</dt><dd>
+XXX document other vendor-specific extensions XXX
+</dd></dl>
+
+Any values stored in an extended attribute override the corresponding
+values in the regular tar header.
+Note that compliant readers should ignore the regular fields when they
+are overridden.
+This is important, as existing archivers are known to store non-compliant
+values in the standard header fields in this situation.
+There are no limits on length for any of these fields.
+In particular, numeric fields can be arbitrarily large.
+All text fields are encoded in UTF8.
+Compliant writers should store only portable 7-bit ASCII characters in
+the standard ustar header and use extended
+attributes whenever a text value contains non-ASCII characters.
+
+In addition to the
+*x*
+entry described above, the pax interchange format
+also supports a
+*g*
+entry.
+The
+*g*
+entry is identical in format, but specifies attributes that serve as
+defaults for all subsequent archive entries.
+The
+*g*
+entry is not widely used.
+
+Besides the new
+*x*
+and
+*g*
+entries, the pax interchange format has a few other minor variations
+from the earlier ustar format.
+The most troubling one is that hardlinks are permitted to have
+data following them.
+This allows readers to restore any hardlink to a file without
+having to rewind the archive to find an earlier entry.
+However, it creates complications for robust readers, as it is no longer
+clear whether or not they should ignore the size field for hardlink entries.
+=== GNU Tar Archives===
+The GNU tar program started with a pre-POSIX format similar to that
+described earlier and has extended it using several different mechanisms:
+It added new fields to the empty space in the header (some of which was later
+used by POSIX for conflicting purposes);
+it allowed the header to be continued over multiple records;
+and it defined new entries that modify following entries
+(similar in principle to the
+*x*
+entry described above, but each GNU special entry is single-purpose,
+unlike the general-purpose
+*x*
+entry).
+As a result, GNU tar archives are not POSIX compatible, although
+more lenient POSIX-compliant readers can successfully extract most
+GNU tar archives.
+{{{
+struct header_gnu_tar {
+	char name[100];
+	char mode[8];
+	char uid[8];
+	char gid[8];
+	char size[12];
+	char mtime[12];
+	char checksum[8];
+	char typeflag[1];
+	char linkname[100];
+	char magic[6];
+	char version[2];
+	char uname[32];
+	char gname[32];
+	char devmajor[8];
+	char devminor[8];
+	char atime[12];
+	char ctime[12];
+	char offset[12];
+	char longnames[4];
+	char unused[1];
+	struct {
+		char offset[12];
+		char numbytes[12];
+	} sparse[4];
+	char isextended[1];
+	char realsize[12];
+	char pad[17];
+};
+}}}
+<dl>
+<dt>_typeflag_</dt><dd>
+GNU tar uses the following special entry types, in addition to
+those defined by POSIX:
+<dl>
+<dt>7</dt><dd>
+GNU tar treats type "7" records identically to type "0" records,
+except on one obscure RTOS where they are used to indicate the
+pre-allocation of a contiguous file on disk.
+</dd><dt>D</dt><dd>
+This indicates a directory entry.
+Unlike the POSIX-standard "5"
+typeflag, the header is followed by data records listing the names
+of files in this directory.
+Each name is preceded by an ASCII "Y"
+if the file is stored in this archive or "N" if the file is not
+stored in this archive.
+Each name is terminated with a null, and
+an extra null marks the end of the name list.
+The purpose of this
+entry is to support incremental backups; a program restoring from
+such an archive may wish to delete files on disk that did not exist
+in the directory when the archive was made.
+
+Note that the "D" typeflag specifically violates POSIX, which requires
+that unrecognized typeflags be restored as normal files.
+In this case, restoring the "D" entry as a file could interfere
+with subsequent creation of the like-named directory.
+</dd><dt>K</dt><dd>
+The data for this entry is a long linkname for the following regular entry.
+</dd><dt>L</dt><dd>
+The data for this entry is a long pathname for the following regular entry.
+</dd><dt>M</dt><dd>
+This is a continuation of the last file on the previous volume.
+GNU multi-volume archives guarantee that each volume begins with a valid
+entry header.
+To ensure this, a file may be split, with part stored at the end of one volume,
+and part stored at the beginning of the next volume.
+The "M" typeflag indicates that this entry continues an existing file.
+Such entries can only occur as the first or second entry
+in an archive (the latter only if the first entry is a volume label).
+The
+_size_
+field specifies the size of this entry.
+The
+_offset_
+field at bytes 369-380 specifies the offset where this file fragment
+begins.
+The
+_realsize_
+field specifies the total size of the file (which must equal
+_size_
+plus
+_offset_).
+When extracting, GNU tar checks that the header file name is the one it is
+expecting, that the header offset is in the correct sequence, and that
+the sum of offset and size is equal to realsize.
+</dd><dt>N</dt><dd>
+Type "N" records are no longer generated by GNU tar.
+They contained a
+list of files to be renamed or symlinked after extraction; this was
+originally used to support long names.
+The contents of this record
+are a text description of the operations to be done, in the form
+"Rename %s to %s\en"
+or
+"Symlink %s to %s\en ;"
+in either case, both
+filenames are escaped using K&R C syntax.
+Due to security concerns, "N" records are now generally ignored
+when reading archives.
+</dd><dt>S</dt><dd>
+This is a
+"sparse"
+regular file.
+Sparse files are stored as a series of fragments.
+The header contains a list of fragment offset/length pairs.
+If more than four such entries are required, the header is
+extended as necessary with
+"extra"
+header extensions (an older format that is no longer used), or
+"sparse"
+extensions.
+</dd><dt>V</dt><dd>
+The
+_name_
+field should be interpreted as a tape/volume header name.
+This entry should generally be ignored on extraction.
+</dd></dl>
+</dd><dt>_magic_</dt><dd>
+The magic field holds the five characters
+"ustar"
+followed by a space.
+Note that POSIX ustar archives have a trailing null.
+</dd><dt>_version_</dt><dd>
+The version field holds a space character followed by a null.
+Note that POSIX ustar archives use two copies of the ASCII digit
+"0".
+</dd><dt>_atime_, _ctime_</dt><dd>
+The time the file was last accessed and the time of
+last change of file information, stored in octal as with
+_mtime_.
+</dd><dt>_longnames_</dt><dd>
+This field is apparently no longer used.
+</dd><dt>Sparse _offset_ / _numbytes_</dt><dd>
+Each such structure specifies a single fragment of a sparse
+file.
+The two fields store values as octal numbers.
+The fragments are each padded to a multiple of 512 bytes
+in the archive.
+On extraction, the list of fragments is collected from the
+header (including any extension headers), and the data
+is then read and written to the file at appropriate offsets.
+</dd><dt>_isextended_</dt><dd>
+If this is set to non-zero, the header will be followed by additional
+"sparse header"
+records.
+Each such record contains information about as many as 21 additional
+sparse blocks as shown here:
+{{{
+struct gnu_sparse_header {
+	struct {
+		char offset[12];
+		char numbytes[12];
+	} sparse[21];
+	char    isextended[1];
+	char    padding[7];
+};
+}}}
+</dd><dt>_realsize_</dt><dd>
+A binary representation of the file's complete size, with a much larger range
+than the POSIX file size.
+In particular, with
+*M*
+type files, the current entry is only a portion of the file.
+In that case, the POSIX size field will indicate the size of this
+entry; the
+_realsize_
+field will indicate the total size of the file.
+</dd></dl>
+=== GNU tar pax archives===
+GNU tar 1.14 (XXX check this XXX) and later will write
+pax interchange format archives when you specify the
+*--posix*
+flag.
+This format uses custom keywords to store sparse file information.
+There have been three iterations of this support, referred to
+as
+"0.0",
+"0.1",
+and
+"1.0".
+<dl>
+<dt>*GNU.sparse.numblocks*, *GNU.sparse.offset*, *GNU.sparse.numbytes*, *GNU.sparse.size*</dt><dd>
+The
+"0.0"
+format used an initial
+*GNU.sparse.numblocks*
+attribute to indicate the number of blocks in the file, a pair of
+*GNU.sparse.offset*
+and
+*GNU.sparse.numbytes*
+to indicate the offset and size of each block,
+and a single
+*GNU.sparse.size*
+to indicate the full size of the file.
+This is not the same as the size in the tar header because the
+latter value does not include the size of any holes.
+This format required that the order of attributes be preserved and
+relied on readers accepting multiple appearances of the same attribute
+names, which is not officially permitted by the standards.
+</dd><dt>*GNU.sparse.map*</dt><dd>
+The
+"0.1"
+format used a single attribute that stored a comma-separated
+list of decimal numbers.
+Each pair of numbers indicated the offset and size, respectively,
+of a block of data.
+This does not work well if the archive is extracted by an archiver
+that does not recognize this extension, since many pax implementations
+simply discard unrecognized attributes.
+</dd><dt>*GNU.sparse.major*, *GNU.sparse.minor*, *GNU.sparse.name*, *GNU.sparse.realsize*</dt><dd>
+The
+"1.0"
+format stores the sparse block map in one or more 512-byte blocks
+prepended to the file data in the entry body.
+The pax attributes indicate the existence of this map
+(via the
+*GNU.sparse.major*
+and
+*GNU.sparse.minor*
+fields)
+and the full size of the file.
+The
+*GNU.sparse.name*
+holds the true name of the file.
+To avoid confusion, the name stored in the regular tar header
+is a modified name so that extraction errors will be apparent
+to users.
+</dd></dl>
+=== Solaris Tar===
+XXX More Details Needed XXX
+
+Solaris tar (beginning with SunOS XXX 5.7 ?? XXX) supports an
+"extended"
+format that is fundamentally similar to pax interchange format,
+with the following differences:
+<ul>
+<li>
+Extended attributes are stored in an entry whose type is
+*X*,
+not
+*x*,
+as used by pax interchange format.
+The detailed format of this entry appears to be the same
+as detailed above for the
+*x*
+entry.
+</li><li>
+An additional
+*A*
+entry is used to store an ACL for the following regular entry.
+The body of this entry contains a seven-digit octal number
+followed by a zero byte, followed by the
+textual ACL description.
+The octal value is the number of ACL entries
+plus a constant that indicates the ACL type: 01000000
+for POSIX.1e ACLs and 03000000 for NFSv4 ACLs.
+</li></ul>
+=== AIX Tar===
+XXX More details needed XXX
+=== Mac OS X Tar===
+The tar distributed with Apple's Mac OS X stores most regular files
+as two separate entries in the tar archive.
+The two entries have the same name except that the first
+one has
+"._"
+added to the beginning of the name.
+This first entry stores the
+"resource fork"
+with additional attributes for the file.
+The Mac OS X
+*CopyFile*()
+API is used to separate a file on disk into separate
+resource and data streams and to reassemble those separate
+streams when the file is restored to disk.
+=== Other Extensions===
+One obvious extension to increase the size of files is to
+eliminate the terminating characters from the various
+numeric fields.
+For example, the standard only allows the size field to contain
+11 octal digits, reserving the twelfth byte for a trailing
+NUL character.
+Allowing 12 octal digits allows file sizes up to 64 GB.
+
+Another extension, utilized by GNU tar, star, and other newer
+*tar*
+implementations, permits binary numbers in the standard numeric fields.
+This is flagged by setting the high bit of the first byte.
+This permits 95-bit values for the length and time fields
+and 63-bit values for the uid, gid, and device numbers.
+GNU tar supports this extension for the
+length, mtime, ctime, and atime fields.
+Joerg Schilling's star program supports this extension for
+all numeric fields.
+Note that this extension is largely obsoleted by the extended attribute
+record provided by the pax interchange format.
+
+Another early GNU extension allowed base-64 values rather than octal.
+This extension was short-lived and is no longer supported by any
+implementation.
+== SEE ALSO ==
+*ar*(1),
+*pax*(1),
+*tar*(1)
+== STANDARDS ==
+The
+*tar*
+utility is no longer a part of POSIX or the Single Unix Standard.
+It last appeared in
+Version 2 of the Single UNIX Specification (``SUSv2'').
+It has been supplanted in subsequent standards by
+*pax*(1).
+The ustar format is currently part of the specification for the
+*pax*(1)
+utility.
+The pax interchange file format is new with
+IEEE Std 1003.1-2001 (``POSIX.1'').
+== HISTORY ==
+A
+*tar*
+command appeared in Seventh Edition Unix, which was released in January, 1979.
+It replaced the
+*tp*
+program from Fourth Edition Unix which in turn replaced the
+*tap*
+program from First Edition Unix.
+John Gilmore's
+*pdtar*
+public-domain implementation (circa 1987) was highly influential
+and formed the basis of
+*GNU* tar
+(circa 1988).
+Joerg Shilling's
+*star*
+archiver is another open-source (GPL) archiver (originally developed
+circa 1985) which features complete support for pax interchange
+format.
+
+This documentation was written as part of the
+*libarchive*
+and
+*bsdtar*
+project by
+Tim Kientzle  <kientzle@FreeBSD.org.>