diff options
| author | Tomas Bzatek <tbzatek@redhat.com> | 2023-12-17 16:55:58 +0100 |
|---|---|---|
| committer | Tomas Bzatek <tbzatek@redhat.com> | 2023-12-17 16:55:58 +0100 |
| commit | b22a4476a66a913a07d5e80334c0400a9b162206 (patch) | |
| tree | d896eb5f6f9212b5ef424219c45571ce5f152cc0 /libarchive/libarchive-2.8.0/doc/html/tar.5.html | |
| parent | 7592788feb1a8cb79b85e6a9911a206a5d55896d (diff) | |
| download | tuxcmd-modules-b22a4476a66a913a07d5e80334c0400a9b162206.tar.xz | |
libarchive: Remove in-tree libarchive package
Libarchive has become a standard package in most distributions,
no need to carry the sources along here.
Diffstat (limited to 'libarchive/libarchive-2.8.0/doc/html/tar.5.html')
| -rw-r--r-- | libarchive/libarchive-2.8.0/doc/html/tar.5.html | 1400 |
1 files changed, 0 insertions, 1400 deletions
diff --git a/libarchive/libarchive-2.8.0/doc/html/tar.5.html b/libarchive/libarchive-2.8.0/doc/html/tar.5.html deleted file mode 100644 index 1d87324..0000000 --- a/libarchive/libarchive-2.8.0/doc/html/tar.5.html +++ /dev/null @@ -1,1400 +0,0 @@ -<!-- Creator : groff version 1.19.2 --> -<!-- CreationDate: Thu Feb 4 20:36:38 2010 --> -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" -"http://www.w3.org/TR/html4/loose.dtd"> -<html> -<head> -<meta name="generator" content="groff -Thtml, see www.gnu.org"> -<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> -<meta name="Content-Style" content="text/css"> -<style type="text/css"> - p { margin-top: 0; margin-bottom: 0; } - pre { margin-top: 0; margin-bottom: 0; } - table { margin-top: 0; margin-bottom: 0; } -</style> -<title></title> -</head> -<body> - -<hr> - - -<p valign="top">tar(5) FreeBSD File Formats Manual -tar(5)</p> - -<p style="margin-top: 1em" valign="top"><b>NAME</b></p> - -<p style="margin-left:8%;"><b>tar</b> — format of -tape archive files</p> - - -<p style="margin-top: 1em" valign="top"><b>DESCRIPTION</b></p> - -<p style="margin-left:8%;">The <b>tar</b> 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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>General -Format</b> <br> -A <b>tar</b> 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.</p> - -<p style="margin-left:8%; margin-top: 1em">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 <b>pdtar</b>.)</p> - -<p style="margin-left:8%; margin-top: 1em"><b>Old-Style -Archive Format</b> <br> -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.</p> - -<p style="margin-left:8%; margin-top: 1em">The header -record for an old-style <b>tar</b> archive consists of the -following:</p> - -<p style="margin-left:17%; margin-top: 1em">struct -header_old_tar {</p> - -<table width="100%" border=0 rules="none" frame="void" - cellspacing="0" cellpadding="0"> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char name[100];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char mode[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char uid[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char gid[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char size[12];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char mtime[12];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char checksum[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char linkflag[1];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char linkname[100];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char pad[255];</p></td> -<td width="58%"> -</td> -</table> - -<p style="margin-left:17%;">};</p> - -<p style="margin-left:8%;">All unused bytes in the header -record are filled with nulls.</p> - -<p style="margin-top: 1em" valign="top"><i>name</i></p> - -<p style="margin-left:20%; margin-top: 1em">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.</p> - -<p style="margin-top: 1em" valign="top"><i>mode</i></p> - -<p style="margin-left:20%; margin-top: 1em">File mode, -stored as an octal number in ASCII.</p> - -<p style="margin-top: 1em" valign="top"><i>uid</i>, -<i>gid</i></p> - -<p style="margin-left:20%;">User id and group id of owner, -as octal numbers in ASCII.</p> - -<p style="margin-top: 1em" valign="top"><i>size</i></p> - -<p style="margin-left:20%; margin-top: 1em">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.</p> - -<p style="margin-top: 1em" valign="top"><i>mtime</i></p> - -<p style="margin-left:20%; margin-top: 1em">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.</p> - - -<p style="margin-top: 1em" valign="top"><i>checksum</i></p> - -<p style="margin-left:20%;">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.</p> - -<p style="margin-top: 1em" valign="top"><i>linkflag</i>, -<i>linkname</i></p> - -<p style="margin-left:20%;">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 <i>linkflag</i> is set to -an ASCII ‘1’ and the <i>linkname</i> field holds -the first name under which this file appears. (Note that -regular files have a null value in the <i>linkflag</i> -field.)</p> - -<p style="margin-left:8%; margin-top: 1em">Early tar -implementations varied in how they terminated these fields. -The tar command in Version 7 AT&T UNIX 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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>Pre-POSIX -Archives</b> <br> -An early draft of IEEE Std 1003.1-1988 -(‘‘POSIX.1’’) served as the basis -for John Gilmore’s <b>pdtar</b> 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:</p> - -<p valign="top"><b>•</b></p> - -<p style="margin-left:20%;">The magic value is -‘‘ustar ’’ (note the following -space). The version field contains a space character -followed by a null.</p> - -<p valign="top"><b>•</b></p> - -<p style="margin-left:20%;">The numeric fields are -generally filled with leading spaces (not leading zeros as -recommended in the final standard).</p> - -<p valign="top"><b>•</b></p> - -<p style="margin-left:20%;">The prefix field is often not -used, limiting pathnames to the 100 characters of old-style -archives.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>POSIX ustar -Archives</b> <br> -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:</p> - -<p style="margin-left:17%; margin-top: 1em">struct -header_posix_ustar {</p> - -<table width="100%" border=0 rules="none" frame="void" - cellspacing="0" cellpadding="0"> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char name[100];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char mode[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char uid[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char gid[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char size[12];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char mtime[12];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char checksum[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char typeflag[1];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char linkname[100];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char magic[6];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char version[2];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char uname[32];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char gname[32];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char devmajor[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char devminor[8];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char prefix[155];</p></td> -<td width="58%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char pad[12];</p></td> -<td width="58%"> -</td> -</table> - -<p style="margin-left:17%;">};</p> - - -<p style="margin-top: 1em" valign="top"><i>typeflag</i></p> - -<p style="margin-left:20%;">Type of entry. POSIX extended -the earlier <i>linkflag</i> field with several new type -values:</p> - -<p valign="top">‘‘0’’</p> - -<p style="margin-left:32%; margin-top: 1em">Regular file. -NUL should be treated as a synonym, for compatibility -purposes.</p> - -<p valign="top">‘‘1’’</p> - -<p style="margin-left:32%; margin-top: 1em">Hard link.</p> - -<p valign="top">‘‘2’’</p> - -<p style="margin-left:32%; margin-top: 1em">Symbolic -link.</p> - -<p valign="top">‘‘3’’</p> - -<p style="margin-left:32%; margin-top: 1em">Character -device node.</p> - -<p valign="top">‘‘4’’</p> - -<p style="margin-left:32%; margin-top: 1em">Block device -node.</p> - -<p valign="top">‘‘5’’</p> - -<p style="margin-left:32%; margin-top: 1em">Directory.</p> - -<p valign="top">‘‘6’’</p> - -<p style="margin-left:32%; margin-top: 1em">FIFO node.</p> - -<p valign="top">‘‘7’’</p> - -<p style="margin-left:32%; margin-top: 1em">Reserved.</p> - -<p valign="top">Other</p> - -<p style="margin-left:32%; margin-top: 1em">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.</p> - -<p style="margin-left:20%;">It is worth noting that the -<i>size</i> 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.</p> - -<p style="margin-top: 1em" valign="top"><i>magic</i></p> - -<p style="margin-left:20%; margin-top: 1em">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.</p> - -<p style="margin-top: 1em" valign="top"><i>version</i></p> - -<p style="margin-left:20%;">Version. This should be -‘‘00’’ (two copies of the ASCII -digit zero) for POSIX standard archives.</p> - -<p style="margin-top: 1em" valign="top"><i>uname</i>, -<i>gname</i></p> - -<p style="margin-left:20%;">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.</p> - -<p style="margin-top: 1em" valign="top"><i>devmajor</i>, -<i>devminor</i></p> - -<p style="margin-left:20%;">Major and minor numbers for -character device or block device entry.</p> - -<p style="margin-top: 1em" valign="top"><i>name</i>, -<i>prefix</i></p> - -<p style="margin-left:20%;">If the pathname is too long to -fit in the 100 bytes provided by the standard format, it can -be split at any <i>/</i> 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 -<i>/</i> character to the regular name field to obtain the -full pathname. The standard does not require a trailing -<i>/</i> character on directory names, though most -implementations still include this for compatibility -reasons.</p> - -<p style="margin-left:8%; margin-top: 1em">Note that all -unused bytes must be set to NUL.</p> - -<p style="margin-left:8%; margin-top: 1em">Field -termination is specified slightly differently by POSIX than -by previous implementations. The <i>magic</i>, <i>uname</i>, -and <i>gname</i> fields must have a trailing NUL. The -<i>pathname</i>, <i>linkname</i>, and <i>prefix</i> 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 <i>/</i> 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.</p> - -<p style="margin-left:8%; margin-top: 1em">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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>Pax -Interchange Format</b> <br> -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.</p> - -<p style="margin-left:8%; margin-top: 1em">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:</p> - -<p style="margin-left:17%;">25 ctime=1084839148.1212\n</p> - -<p style="margin-left:8%;">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:</p> - -<p style="margin-top: 1em" valign="top"><b>atime</b>, -<b>ctime</b>, <b>mtime</b></p> - -<p style="margin-left:20%;">File access, inode change, and -modification times. These fields can be negative or include -a decimal point and a fractional value.</p> - -<p style="margin-top: 1em" valign="top"><b>uname</b>, -<b>uid</b>, <b>gname</b>, <b>gid</b></p> - -<p style="margin-left:20%;">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.</p> - - -<p style="margin-top: 1em" valign="top"><b>linkpath</b></p> - -<p style="margin-left:20%;">The full path of the linked-to -file. Note that this is encoded in UTF8 and can thus include -non-ASCII characters.</p> - -<p style="margin-top: 1em" valign="top"><b>path</b></p> - -<p style="margin-left:20%; margin-top: 1em">The full -pathname of the entry. Note that this is encoded in UTF8 and -can thus include non-ASCII characters.</p> - -<p style="margin-top: 1em" valign="top"><b>realtime.*</b>, -<b>security.*</b></p> - -<p style="margin-left:20%;">These keys are reserved and may -be used for future standardization.</p> - -<p style="margin-top: 1em" valign="top"><b>size</b></p> - -<p style="margin-left:20%; margin-top: 1em">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.</p> - - -<p style="margin-top: 1em" valign="top"><b>SCHILY.*</b></p> - -<p style="margin-left:20%;">Vendor-specific attributes used -by Joerg Schilling’s <b>star</b> implementation.</p> - - -<p style="margin-top: 1em" valign="top"><b>SCHILY.acl.access</b>, -<b>SCHILY.acl.default</b></p> - -<p style="margin-left:20%;">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).</p> - - -<p style="margin-top: 1em" valign="top"><b>SCHILY.devminor</b>, -<b>SCHILY.devmajor</b></p> - -<p style="margin-left:20%;">The full minor and major -numbers for device nodes.</p> - - -<p style="margin-top: 1em" valign="top"><b>SCHILY.fflags</b></p> - -<p style="margin-left:20%;">The file flags.</p> - - -<p style="margin-top: 1em" valign="top"><b>SCHILY.realsize</b></p> - -<p style="margin-left:20%;">The full size of the file on -disk. XXX explain? XXX</p> - -<p style="margin-top: 1em" valign="top"><b>SCHILY.dev, -SCHILY.ino</b>, <b>SCHILY.nlinks</b></p> - -<p style="margin-left:20%;">The device number, inode -number, and link count for the entry. In particular, note -that a pax interchange format archive using Joerg -Schilling’s <b>SCHILY.*</b> extensions can store all -of the data from <i>struct stat</i>.</p> - - -<p style="margin-top: 1em" valign="top"><b>LIBARCHIVE.xattr.</b><i>namespace</i>.<i>key</i></p> - -<p style="margin-left:20%;">Libarchive stores -POSIX.1e-style extended attributes using keys of this form. -The <i>key</i> 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</p> - - -<p style="margin-top: 1em" valign="top"><b>VENDOR.*</b></p> - -<p style="margin-left:20%;">XXX document other -vendor-specific extensions XXX</p> - -<p style="margin-left:8%; margin-top: 1em">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.</p> - -<p style="margin-left:8%; margin-top: 1em">In addition to -the <b>x</b> entry described above, the pax interchange -format also supports a <b>g</b> entry. The <b>g</b> entry is -identical in format, but specifies attributes that serve as -defaults for all subsequent archive entries. The <b>g</b> -entry is not widely used.</p> - -<p style="margin-left:8%; margin-top: 1em">Besides the new -<b>x</b> and <b>g</b> 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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>GNU Tar -Archives</b> <br> -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 -<b>x</b> entry described above, but each GNU special entry -is single-purpose, unlike the general-purpose <b>x</b> -entry). As a result, GNU tar archives are not POSIX -compatible, although more lenient POSIX-compliant readers -can successfully extract most GNU tar archives.</p> - -<p style="margin-left:17%; margin-top: 1em">struct -header_gnu_tar {</p> - -<table width="100%" border=0 rules="none" frame="void" - cellspacing="0" cellpadding="0"> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char name[100];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char mode[8];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char uid[8];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char gid[8];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char size[12];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char mtime[12];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char checksum[8];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char typeflag[1];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char linkname[100];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char magic[6];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char version[2];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char uname[32];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char gname[32];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char devmajor[8];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char devminor[8];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char atime[12];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char ctime[12];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char offset[12];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char longnames[4];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char unused[1];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">struct {</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> -</td> -<td width="12%"> - - -<p valign="top">char offset[12];</p></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> -</td> -<td width="12%"> - - -<p valign="top">char numbytes[12];</p></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">} sparse[4];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char isextended[1];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char realsize[12];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -<tr valign="top" align="left"> -<td width="29%"></td> -<td width="13%"> - - -<p valign="top">char pad[17];</p></td> -<td width="12%"></td> -<td width="46%"> -</td> -</table> - -<p style="margin-left:17%;">};</p> - - -<p style="margin-top: 1em" valign="top"><i>typeflag</i></p> - -<p style="margin-left:20%;">GNU tar uses the following -special entry types, in addition to those defined by -POSIX:</p> - -<p style="margin-top: 1em" valign="top">7</p> - -<p style="margin-left:32%; margin-top: 1em">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.</p> - -<p style="margin-top: 1em" valign="top">D</p> - -<p style="margin-left:32%; margin-top: 1em">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.</p> - -<p style="margin-left:32%; margin-top: 1em">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.</p> - -<p style="margin-top: 1em" valign="top">K</p> - -<p style="margin-left:32%; margin-top: 1em">The data for -this entry is a long linkname for the following regular -entry.</p> - -<p style="margin-top: 1em" valign="top">L</p> - -<p style="margin-left:32%; margin-top: 1em">The data for -this entry is a long pathname for the following regular -entry.</p> - -<p style="margin-top: 1em" valign="top">M</p> - -<p style="margin-left:32%; margin-top: 1em">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 <i>size</i> field specifies the size of -this entry. The <i>offset</i> field at bytes 369-380 -specifies the offset where this file fragment begins. The -<i>realsize</i> field specifies the total size of the file -(which must equal <i>size</i> plus <i>offset</i>). 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.</p> - -<p style="margin-top: 1em" valign="top">N</p> - -<p style="margin-left:32%; margin-top: 1em">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\n’’ or ‘‘Symlink %s to -%s\n’’; 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.</p> - -<p style="margin-top: 1em" valign="top">S</p> - -<p style="margin-left:32%; margin-top: 1em">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.</p> - -<p style="margin-top: 1em" valign="top">V</p> - -<p style="margin-left:32%; margin-top: 1em">The <i>name</i> -field should be interpreted as a tape/volume header name. -This entry should generally be ignored on extraction.</p> - -<p style="margin-top: 1em" valign="top"><i>magic</i></p> - -<p style="margin-left:20%; margin-top: 1em">The magic field -holds the five characters ‘‘ustar’’ -followed by a space. Note that POSIX ustar archives have a -trailing null.</p> - -<p style="margin-top: 1em" valign="top"><i>version</i></p> - -<p style="margin-left:20%;">The version field holds a space -character followed by a null. Note that POSIX ustar archives -use two copies of the ASCII digit -‘‘0’’.</p> - -<p style="margin-top: 1em" valign="top"><i>atime</i>, -<i>ctime</i></p> - -<p style="margin-left:20%;">The time the file was last -accessed and the time of last change of file information, -stored in octal as with <i>mtime</i>.</p> - - -<p style="margin-top: 1em" valign="top"><i>longnames</i></p> - -<p style="margin-left:20%;">This field is apparently no -longer used.</p> - -<p style="margin-top: 1em" valign="top">Sparse <i>offset / -numbytes</i></p> - -<p style="margin-left:20%;">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.</p> - - -<p style="margin-top: 1em" valign="top"><i>isextended</i></p> - -<p style="margin-left:20%;">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:</p> - -<p style="margin-left:29%; margin-top: 1em">struct -gnu_sparse_header {</p> - -<table width="100%" border=0 rules="none" frame="void" - cellspacing="0" cellpadding="0"> -<tr valign="top" align="left"> -<td width="42%"></td> -<td width="12%"> - - -<p valign="top">struct {</p></td> -<td width="12%"></td> -<td width="34%"> -</td> -<tr valign="top" align="left"> -<td width="42%"></td> -<td width="12%"> -</td> -<td width="12%"> - - -<p valign="top">char offset[12];</p></td> -<td width="34%"> -</td> -<tr valign="top" align="left"> -<td width="42%"></td> -<td width="12%"> -</td> -<td width="12%"> - - -<p valign="top">char numbytes[12];</p></td> -<td width="34%"> -</td> -<tr valign="top" align="left"> -<td width="42%"></td> -<td width="12%"> - - -<p valign="top">} sparse[21];</p></td> -<td width="12%"></td> -<td width="34%"> -</td> -<tr valign="top" align="left"> -<td width="42%"></td> -<td width="12%"> - - -<p valign="top">char isextended[1];</p></td> -<td width="12%"></td> -<td width="34%"> -</td> -<tr valign="top" align="left"> -<td width="42%"></td> -<td width="12%"> - - -<p valign="top">char padding[7];</p></td> -<td width="12%"></td> -<td width="34%"> -</td> -</table> - -<p style="margin-left:29%;">};</p> - - -<p style="margin-top: 1em" valign="top"><i>realsize</i></p> - -<p style="margin-left:20%;">A binary representation of the -file’s complete size, with a much larger range than -the POSIX file size. In particular, with <b>M</b> 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 <i>realsize</i> field will indicate the -total size of the file.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>GNU tar pax -archives</b> <br> -GNU tar 1.14 (XXX check this XXX) and later will write pax -interchange format archives when you specify the -<b>−-posix</b> 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’’.</p> - - -<p style="margin-top: 1em" valign="top"><b>GNU.sparse.numblocks</b>, -<b>GNU.sparse.offset</b>, <b>GNU.sparse.numbytes</b>, -<b>GNU.sparse.size</b></p> - -<p style="margin-left:20%;">The -‘‘0.0’’ format used an initial -<b>GNU.sparse.numblocks</b> attribute to indicate the number -of blocks in the file, a pair of <b>GNU.sparse.offset</b> -and <b>GNU.sparse.numbytes</b> to indicate the offset and -size of each block, and a single <b>GNU.sparse.size</b> 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.</p> - - -<p style="margin-top: 1em" valign="top"><b>GNU.sparse.map</b></p> - -<p style="margin-left:20%;">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.</p> - - -<p style="margin-top: 1em" valign="top"><b>GNU.sparse.major</b>, -<b>GNU.sparse.minor</b>, <b>GNU.sparse.name</b>, -<b>GNU.sparse.realsize</b></p> - -<p style="margin-left:20%;">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 <b>GNU.sparse.major</b> and -<b>GNU.sparse.minor</b> fields) and the full size of the -file. The <b>GNU.sparse.name</b> 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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>Solaris -Tar</b> <br> -XXX More Details Needed XXX</p> - -<p style="margin-left:8%; margin-top: 1em">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:</p> - -<p valign="top"><b>•</b></p> - -<p style="margin-left:20%;">Extended attributes are stored -in an entry whose type is <b>X</b>, not <b>x</b>, as used by -pax interchange format. The detailed format of this entry -appears to be the same as detailed above for the <b>x</b> -entry.</p> - -<p valign="top"><b>•</b></p> - -<p style="margin-left:20%;">An additional <b>A</b> 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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>AIX Tar</b> -<br> -XXX More details needed XXX</p> - -<p style="margin-left:8%; margin-top: 1em"><b>Mac OS X -Tar</b> <br> -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 <b>CopyFile</b>() 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.</p> - -<p style="margin-left:8%; margin-top: 1em"><b>Other -Extensions</b> <br> -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.</p> - -<p style="margin-left:8%; margin-top: 1em">Another -extension, utilized by GNU tar, star, and other newer -<b>tar</b> 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.</p> - -<p style="margin-left:8%; margin-top: 1em">Another early -GNU extension allowed base-64 values rather than octal. This -extension was short-lived and is no longer supported by any -implementation.</p> - -<p style="margin-top: 1em" valign="top"><b>SEE ALSO</b></p> - -<p style="margin-left:8%;">ar(1), pax(1), tar(1)</p> - - -<p style="margin-top: 1em" valign="top"><b>STANDARDS</b></p> - -<p style="margin-left:8%;">The <b>tar</b> 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’’).</p> - -<p style="margin-top: 1em" valign="top"><b>HISTORY</b></p> - -<p style="margin-left:8%;">A <b>tar</b> command appeared in -Seventh Edition Unix, which was released in January, 1979. -It replaced the <b>tp</b> program from Fourth Edition Unix -which in turn replaced the <b>tap</b> program from First -Edition Unix. John Gilmore’s <b>pdtar</b> -public-domain implementation (circa 1987) was highly -influential and formed the basis of <b>GNU tar</b> (circa -1988). Joerg Shilling’s <b>star</b> archiver is -another open-source (GPL) archiver (originally developed -circa 1985) which features complete support for pax -interchange format.</p> - -<p style="margin-left:8%; margin-top: 1em">This -documentation was written as part of the <b>libarchive</b> -and <b>bsdtar</b> project by Tim Kientzle -⟨kientzle@FreeBSD.org⟩.</p> - - -<p style="margin-left:8%; margin-top: 1em">FreeBSD 8.0 -December 27, 2009 FreeBSD 8.0</p> -<hr> -</body> -</html> |