diff options
Diffstat (limited to 'archivers/libarchive/files/doc/text/tar.5.txt')
| -rw-r--r-- | archivers/libarchive/files/doc/text/tar.5.txt | 300 |
1 files changed, 150 insertions, 150 deletions
diff --git a/archivers/libarchive/files/doc/text/tar.5.txt b/archivers/libarchive/files/doc/text/tar.5.txt index df37d9feb66..b7d389f59f0 100644 --- a/archivers/libarchive/files/doc/text/tar.5.txt +++ b/archivers/libarchive/files/doc/text/tar.5.txt @@ -1,17 +1,17 @@ TAR(5) BSD File Formats Manual TAR(5) -NAME - tar — format of tape archive files +1mNAME0m + 1mtar 22m— format of tape archive files -DESCRIPTION - The tar archive format collects any number of files, directories, and +1mDESCRIPTION0m + The 1mtar 22marchive 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 + 1mGeneral Format0m + A 1mtar 22marchive 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 @@ -25,16 +25,16 @@ DESCRIPTION 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 fol‐ - lows the convention established by John Gilmore in documenting pdtar.) + lows the convention established by John Gilmore in documenting 1mpdtar22m.) - Old-Style Archive Format + 1mOld-Style Archive Format0m 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 Version 7 AT&T UNIX, 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: + The header record for an old-style 1mtar 22marchive consists of the following: struct header_old_tar { char name[100]; @@ -50,29 +50,29 @@ DESCRIPTION }; All unused bytes in the header record are filled with nulls. - name Pathname, stored as a null-terminated string. Early tar imple‐ + 4mname24m Pathname, stored as a null-terminated string. Early tar imple‐ mentations only stored regular files (including hardlinks to those files). One common early convention used a trailing "/" character to indicate a directory name, allowing directory per‐ missions and owner information to be archived and restored. - mode File mode, stored as an octal number in ASCII. + 4mmode24m File mode, stored as an octal number in ASCII. - uid, gid + 4muid24m, 4mgid0m User id and group id of owner, as octal numbers in ASCII. - size Size of file, as octal number in ASCII. For regular files only, + 4msize24m 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. - mtime Modification time of file, as an octal number in ASCII. This + 4mmtime24m 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. - checksum + 4mchecksum0m 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 @@ -83,13 +83,13 @@ DESCRIPTION Modern robust readers compute the checksum both ways and accept the header if either computation matches. - linkflag, linkname + 4mlinkflag24m, 4mlinkname0m 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 ‘1’ and the linkname field holds the first name + is encountered. The next time it is encountered, the 4mlinkflag24m is + set to an ASCII ‘1’ and the 4mlinkname24m field holds the first name under which this file appears. (Note that regular files have a - null value in the linkflag field.) + null value in the 4mlinkflag24m field.) Early tar implementations varied in how they terminated these fields. The tar command in Version 7 AT&T UNIX used the following conventions @@ -102,20 +102,20 @@ DESCRIPTION For best portability, modern implementations should fill the numeric fields with leading zeros. - Pre-POSIX Archives + 1mPre-POSIX Archives0m 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 + for John Gilmore's 1mpdtar 22mprogram 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: - · The magic value consists of the five characters “ustar” followed + 1m· 22mThe magic value consists of the five characters “ustar” followed by a space. The version field contains a space character fol‐ lowed by a null. - · The numeric fields are generally filled with leading spaces (not + 1m· 22mThe numeric fields are generally filled with leading spaces (not leading zeros as recommended in the final standard). - · The prefix field is often not used, limiting pathnames to the 100 + 1m· 22mThe prefix field is often not used, limiting pathnames to the 100 characters of old-style archives. - POSIX ustar Archives + 1mPOSIX ustar Archives0m 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 @@ -142,8 +142,8 @@ DESCRIPTION char pad[12]; }; - typeflag - Type of entry. POSIX extended the earlier linkflag field with + 4mtypeflag0m + Type of entry. POSIX extended the earlier 4mlinkflag24m field with several new type values: “0” Regular file. NUL should be treated as a synonym, for compatibility purposes. @@ -161,7 +161,7 @@ DESCRIPTION support the corresponding extension. Uppercase letters "A" through "Z" are reserved for custom extensions. Note that sockets and whiteout entries are not archivable. - It is worth noting that the size field, in particular, has dif‐ + It is worth noting that the 4msize24m field, in particular, has dif‐ ferent 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 @@ -169,40 +169,40 @@ DESCRIPTION allocate directory space. For all other types, it should be set to zero by writers and ignored by readers. - magic Contains the magic value “ustar” followed by a NUL byte to indi‐ + 4mmagic24m Contains the magic value “ustar” followed by a NUL byte to indi‐ cate that this is a POSIX standard archive. Full compliance requires the uname and gname fields be properly set. - version + 4mversion0m Version. This should be “00” (two copies of the ASCII digit zero) for POSIX standard archives. - uname, gname + 4muname24m, 4mgname0m 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. - devmajor, devminor + 4mdevmajor24m, 4mdevminor0m Major and minor numbers for character device or block device entry. - name, prefix + 4mname24m, 4mprefix0m 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 + the standard format, it can be split at any 4m/24m 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 / + is not empty, the reader will prepend the prefix value and a 4m/0m character to the regular name field to obtain the full pathname. - The standard does not require a trailing / character on directory + The standard does not require a trailing 4m/24m character on directory names, though most implementations still include this for compat‐ ibility reasons. Note that all unused bytes must be set to NUL. Field termination is specified slightly differently by POSIX than by pre‐ - vious implementations. The magic, uname, and gname fields must have a - trailing NUL. The pathname, linkname, and prefix fields must have a + vious implementations. The 4mmagic24m, 4muname24m, and 4mgname24m fields must have a + trailing NUL. The 4mpathname24m, 4mlinkname24m, and 4mprefix24m 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 + possible to store a 256-character pathname if it happens to have a 4m/24m 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. @@ -211,7 +211,7 @@ DESCRIPTION sionally extending it by adding new fields to the blank area at the end of the header record. - Numeric Extensions + 1mNumeric Extensions0m There have been several attempts to extend the range of sizes or times supported by modifying how numbers are stored in the header. @@ -221,7 +221,7 @@ DESCRIPTION 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 imple‐ + Another extension, utilized by GNU tar, star, and other newer 1mtar 22mimple‐ mentations, permits binary numbers in the standard numeric fields. This is flagged by setting the high bit of the first byte. The remainder of the field is treated as a signed twos-complement value. This permits @@ -237,7 +237,7 @@ DESCRIPTION This extension was short-lived and is no longer supported by any imple‐ mentation. - Pax Interchange Format + 1mPax Interchange Format0m 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 meta‐ @@ -265,12 +265,12 @@ DESCRIPTION that, unlike the historic header, numeric values are stored using deci‐ mal, not octal. A description of some common keys follows: - atime, ctime, mtime + 1matime22m, 1mctime22m, 1mmtime0m File access, inode change, and modification times. These fields can be negative or include a decimal point and a fractional value. - hdrcharset + 1mhdrcharset0m The character set used by the pax extension values. By default, all textual values in the pax extended attributes are assumed to be in UTF-8, including pathnames, user names, and group names. @@ -285,73 +285,73 @@ DESCRIPTION this flag should not be used as a general mechanism to allow filenames to be stored in arbitrary encodings. - uname, uid, gname, gid + 1muname22m, 1muid22m, 1mgname22m, 1mgid0m 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. - linkpath + 1mlinkpath0m The full path of the linked-to file. Note that this is encoded in UTF8 and can thus include non-ASCII characters. - path The full pathname of the entry. Note that this is encoded in + 1mpath 22mThe full pathname of the entry. Note that this is encoded in UTF8 and can thus include non-ASCII characters. - realtime.*, security.* + 1mrealtime.*22m, 1msecurity.*0m These keys are reserved and may be used for future standardiza‐ tion. - size The size of the file. Note that there is no length limit on this + 1msize 22mThe 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. - SCHILY.* - Vendor-specific attributes used by Joerg Schilling's star imple‐ + 1mSCHILY.*0m + Vendor-specific attributes used by Joerg Schilling's 1mstar 22mimple‐ mentation. - SCHILY.acl.access, SCHILY.acl.default - 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). + 1mSCHILY.acl.access22m, 1mSCHILY.acl.default, SCHILY.acl.ace0m + Stores the access, default and NFSv4 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 an additional 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). - SCHILY.devminor, SCHILY.devmajor + 1mSCHILY.devminor22m, 1mSCHILY.devmajor0m The full minor and major numbers for device nodes. - SCHILY.fflags + 1mSCHILY.fflags0m The file flags. - SCHILY.realsize + 1mSCHILY.realsize0m The full size of the file on disk. XXX explain? XXX - SCHILY.dev, SCHILY.ino, SCHILY.nlinks + 1mSCHILY.dev, SCHILY.ino22m, 1mSCHILY.nlinks0m 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. + Joerg Schilling's 1mSCHILY.* 22mextensions can store all of the data + from 4mstruct24m 4mstat24m. - LIBARCHIVE.* - Vendor-specific attributes used by the libarchive library and + 1mLIBARCHIVE.*0m + Vendor-specific attributes used by the 1mlibarchive 22mlibrary and programs that use it. - LIBARCHIVE.creationtime + 1mLIBARCHIVE.creationtime0m The time when the file was created. (This should not be confused with the POSIX “ctime” attribute, which refers to the time when the file metadata was last changed.) - LIBARCHIVE.xattr.namespace.key + 1mLIBARCHIVE.xattr.4m22mnamespace24m.4mkey0m Libarchive stores POSIX.1e-style extended attributes using keys - of this form. The key value is URL-encoded: All non-ASCII char‐ + of this form. The 4mkey24m value is URL-encoded: All non-ASCII char‐ acters 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 - VENDOR.* + 1mVENDOR.*0m XXX document other vendor-specific extensions XXX Any values stored in an extended attribute override the corresponding @@ -365,12 +365,12 @@ DESCRIPTION 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 speci‐ + In addition to the 1mx 22mentry described above, the pax interchange format + also supports a 1mg 22mentry. The 1mg 22mentry is identical in format, but speci‐ fies attributes that serve as defaults for all subsequent archive - entries. The g entry is not widely used. + entries. The 1mg 22mentry is not widely used. - Besides the new x and g entries, the pax interchange format has a few + Besides the new 1mx 22mand 1mg 22mentries, 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 @@ -378,15 +378,15 @@ DESCRIPTION for robust readers, as it is no longer clear whether or not they should ignore the size field for hardlink entries. - GNU Tar Archives + 1mGNU Tar Archives0m 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 mod‐ - ify following entries (similar in principle to the x entry described + ify following entries (similar in principle to the 1mx 22mentry 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 compati‐ + purpose 1mx 22mentry). As a result, GNU tar archives are not POSIX compati‐ ble, although more lenient POSIX-compliant readers can successfully extract most GNU tar archives. @@ -420,7 +420,7 @@ DESCRIPTION char pad[17]; }; - typeflag + 4mtypeflag0m GNU tar uses the following special entry types, in addition to those defined by POSIX: @@ -461,11 +461,11 @@ DESCRIPTION ume. The "M" typeflag indicates that this entry contin‐ ues 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 spec‐ - ifies the size of this entry. The offset field at bytes + the first entry is a volume label). The 4msize24m field spec‐ + ifies the size of this entry. The 4moffset24m 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 + begins. The 4mrealsize24m field specifies the total size of + the file (which must equal 4msize24m plus 4moffset24m). 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 @@ -488,26 +488,26 @@ DESCRIPTION with “extra” header extensions (an older format that is no longer used), or “sparse” extensions. - V The name field should be interpreted as a tape/volume + V The 4mname24m field should be interpreted as a tape/volume header name. This entry should generally be ignored on extraction. - magic The magic field holds the five characters “ustar” followed by a + 4mmagic24m The magic field holds the five characters “ustar” followed by a space. Note that POSIX ustar archives have a trailing null. - version + 4mversion0m The version field holds a space character followed by a null. Note that POSIX ustar archives use two copies of the ASCII digit “0”. - atime, ctime + 4matime24m, 4mctime0m The time the file was last accessed and the time of last change - of file information, stored in octal as with mtime. + of file information, stored in octal as with 4mmtime24m. - longnames + 4mlongnames0m This field is apparently no longer used. - Sparse offset / numbytes + Sparse 4moffset24m 4m/24m 4mnumbytes0m 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 @@ -515,7 +515,7 @@ DESCRIPTION (including any extension headers), and the data is then read and written to the file at appropriate offsets. - isextended + 4misextended0m If this is set to non-zero, the header will be followed by addi‐ tional “sparse header” records. Each such record contains infor‐ mation about as many as 21 additional sparse blocks as shown @@ -530,28 +530,28 @@ DESCRIPTION char padding[7]; }; - realsize + 4mrealsize0m A binary representation of the file's complete size, with a much - larger range than the POSIX file size. In particular, with M + larger range than the POSIX file size. In particular, with 1mM0m 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 + entry; the 4mrealsize24m field will indicate the total size of the file. - GNU tar pax archives + 1mGNU tar pax archives0m GNU tar 1.14 (XXX check this XXX) and later will write pax interchange - format archives when you specify the --posix flag. This format follows - the pax interchange format closely, using some SCHILY tags and introduc‐ + format archives when you specify the 1m--posix 22mflag. This format follows + the pax interchange format closely, using some 1mSCHILY 22mtags and introduc‐ ing new keywords to store sparse file information. There have been three iterations of the sparse file support, referred to as “0.0”, “0.1”, and “1.0”. - GNU.sparse.numblocks, GNU.sparse.offset, GNU.sparse.numbytes, - GNU.sparse.size - The “0.0” format used an initial GNU.sparse.numblocks attribute + 1mGNU.sparse.numblocks22m, 1mGNU.sparse.offset22m, 1mGNU.sparse.numbytes22m, + 1mGNU.sparse.size0m + The “0.0” format used an initial 1mGNU.sparse.numblocks 22mattribute 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 + 1mGNU.sparse.offset 22mand 1mGNU.sparse.numbytes 22mto indicate the offset + and size of each block, and a single 1mGNU.sparse.size 22mto 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 @@ -559,7 +559,7 @@ DESCRIPTION of the same attribute names, which is not officially permitted by the standards. - GNU.sparse.map + 1mGNU.sparse.map0m The “0.1” format used a single attribute that stored a comma-sep‐ arated list of decimal numbers. Each pair of numbers indicated the offset and size, respectively, of a block of data. This does @@ -567,50 +567,50 @@ DESCRIPTION does not recognize this extension, since many pax implementations simply discard unrecognized attributes. - GNU.sparse.major, GNU.sparse.minor, GNU.sparse.name, GNU.sparse.realsize + 1mGNU.sparse.major22m, 1mGNU.sparse.minor22m, 1mGNU.sparse.name22m, 1mGNU.sparse.realsize0m 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 + 1mGNU.sparse.major 22mand 1mGNU.sparse.minor 22mfields) and the full size + of the file. The 1mGNU.sparse.name 22mholds 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. - Solaris Tar + 1mSolaris Tar0m 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: - · 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 + 1m· 22mExtended attributes are stored in an entry whose type is 1mX22m, not + 1mx22m, as used by pax interchange format. The detailed format of + this entry appears to be the same as detailed above for the 1mx0m entry. - · An additional A header is used to store an ACL for the following + 1m· 22mAn additional 1mA 22mheader 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. - AIX Tar + 1mAIX Tar0m XXX More details needed XXX - AIX Tar uses a ustar-formatted header with the type A for storing coded + AIX Tar uses a ustar-formatted header with the type 1mA 22mfor storing coded ACL information. Unlike the Solaris format, AIX tar writes this header after the regular file body to which it applies. The pathname in this - header is either NFS4 or AIXC to indicate the type of ACL stored. The + header is either 1mNFS4 22mor 1mAIXC 22mto indicate the type of ACL stored. The actual ACL is stored in platform-specific binary format. - Mac OS X Tar + 1mMac OS X Tar0m The tar distributed with Apple's Mac OS X stores most regular files as two separate files in the tar archive. The two files have the same name except that the first one has “._” prepended to the last path element. This special file stores an AppleDouble-encoded binary blob with addi‐ tional metadata about the second file, including ACL, extended attributes, and resources. To recreate the original file on disk, each - separate file can be extracted and the Mac OS X copyfile() function can + separate file can be extracted and the Mac OS X 1mcopyfile22m() function can be used to unpack the separate metadata file and apply it to th regular file. Conversely, the same function provides a “pack” option to encode the extended metadata from a file into a separate file whose contents can @@ -621,54 +621,54 @@ DESCRIPTION extensions needs to be included in the archive for each one, doubling the overhead required for files with long names. - Summary of tar type codes + 1mSummary of tar type codes0m The following list is a condensed summary of the type codes used in tar header records generated by different tar implementations. More details about specific implementations can be found above: NUL Early tar programs stored a zero byte for regular files. - 0 POSIX standard type code for a regular file. - 1 POSIX standard type code for a hard link description. - 2 POSIX standard type code for a symbolic link description. - 3 POSIX standard type code for a character device node. - 4 POSIX standard type code for a block device node. - 5 POSIX standard type code for a directory. - 6 POSIX standard type code for a FIFO. - 7 POSIX reserved. - 7 GNU tar used for pre-allocated files on some systems. - A Solaris tar ACL description stored prior to a regular file header. - A AIX tar ACL description stored after the file body. - D GNU tar directory dump. - K GNU tar long linkname for the following header. - L GNU tar long pathname for the following header. - M GNU tar multivolume marker, indicating the file is a continuation of + 1m0 22mPOSIX standard type code for a regular file. + 1m1 22mPOSIX standard type code for a hard link description. + 1m2 22mPOSIX standard type code for a symbolic link description. + 1m3 22mPOSIX standard type code for a character device node. + 1m4 22mPOSIX standard type code for a block device node. + 1m5 22mPOSIX standard type code for a directory. + 1m6 22mPOSIX standard type code for a FIFO. + 1m7 22mPOSIX reserved. + 1m7 22mGNU tar used for pre-allocated files on some systems. + 1mA 22mSolaris tar ACL description stored prior to a regular file header. + 1mA 22mAIX tar ACL description stored after the file body. + 1mD 22mGNU tar directory dump. + 1mK 22mGNU tar long linkname for the following header. + 1mL 22mGNU tar long pathname for the following header. + 1mM 22mGNU tar multivolume marker, indicating the file is a continuation of a file from the previous volume. - N GNU tar long filename support. Deprecated. - S GNU tar sparse regular file. - V GNU tar tape/volume header name. - X Solaris tar general-purpose extension header. - g POSIX pax interchange format global extensions. - x POSIX pax interchange format per-file extensions. - -SEE ALSO + 1mN 22mGNU tar long filename support. Deprecated. + 1mS 22mGNU tar sparse regular file. + 1mV 22mGNU tar tape/volume header name. + 1mX 22mSolaris tar general-purpose extension header. + 1mg 22mPOSIX pax interchange format global extensions. + 1mx 22mPOSIX pax interchange format per-file extensions. + +1mSEE ALSO0m ar(1), pax(1), tar(1) -STANDARDS - The tar utility is no longer a part of POSIX or the Single Unix Standard. +1mSTANDARDS0m + The 1mtar 22mutility 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 for‐ mat 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 +1mHISTORY0m + A 1mtar 22mcommand appeared in Seventh Edition Unix, which was released in + January, 1979. It replaced the 1mtp 22mprogram from Fourth Edition Unix which + in turn replaced the 1mtap 22mprogram from First Edition Unix. John Gilmore's + 1mpdtar 22mpublic-domain implementation (circa 1987) was highly influential + and formed the basis of 1mGNU tar 22m(circa 1988). Joerg Shilling's 1mstar0m archiver is another open-source (CDDL) archiver (originally developed circa 1985) which features complete support for pax interchange format. - This documentation was written as part of the libarchive and bsdtar + This documentation was written as part of the 1mlibarchive 22mand 1mbsdtar0m project by Tim Kientzle <kientzle@FreeBSD.org>. -BSD December 23, 2011 BSD +BSD December 27, 2016 BSD |