diff options
| author | Tomas Bzatek <tbzatek@redhat.com> | 2010-02-05 11:06:31 +0100 |
|---|---|---|
| committer | Tomas Bzatek <tbzatek@redhat.com> | 2010-02-05 11:06:31 +0100 |
| commit | baea7d877d3cf69679a39e8512a120658a478073 (patch) | |
| tree | 37c9a98cb3d3a322f3f91c8ca656ccd6bd2eaebe /libarchive/libarchive-2.8.0/doc/html/tar.5.html | |
| parent | e42a4ff3031aa1c1aaf27aa34d9395fec185924b (diff) | |
| download | tuxcmd-modules-baea7d877d3cf69679a39e8512a120658a478073.tar.xz | |
Rebase libarchive to 2.8.0
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, 1400 insertions, 0 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 new file mode 100644 index 0000000..1d87324 --- /dev/null +++ b/libarchive/libarchive-2.8.0/doc/html/tar.5.html @@ -0,0 +1,1400 @@ +<!-- 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> |