libarchive: Remove in-tree libarchive package

Libarchive has become a standard package in most distributions,
no need to carry the sources along here.

1 files changed, 0 insertions, 805 deletions

diff --git a/libarchive/libarchive-2.8.0/doc/wiki/ManPageTar5.wiki b/libarchive/libarchive-2.8.0/doc/wiki/ManPageTar5.wiki
deleted file mode 100644
index 12fd514..0000000
--- a/libarchive/libarchive-2.8.0/doc/wiki/ManPageTar5.wiki
+++ /dev/null
@@ -1,805 +0,0 @@
-#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.>