diff options
Diffstat (limited to 'archivers/libarchive/files/doc/html/tar.5.html')
| -rw-r--r-- | archivers/libarchive/files/doc/html/tar.5.html | 281 |
1 files changed, 135 insertions, 146 deletions
diff --git a/archivers/libarchive/files/doc/html/tar.5.html b/archivers/libarchive/files/doc/html/tar.5.html index c9af4d8acf9..a718b1d2f7e 100644 --- a/archivers/libarchive/files/doc/html/tar.5.html +++ b/archivers/libarchive/files/doc/html/tar.5.html @@ -1,5 +1,5 @@ -<!-- Creator : groff version 1.22.3 --> -<!-- CreationDate: Mon Sep 3 22:55:10 2018 --> +<!-- Creator : groff version 1.22.4 --> +<!-- CreationDate: Wed Jun 12 21:10:19 2019 --> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> @@ -50,16 +50,15 @@ entirely of zero bytes.</p> 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 +“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> +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:6%; margin-top: 1em"><b>Old-Style Archive Format</b> <br> @@ -239,25 +238,25 @@ 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> +(“POSIX.1”) standard was released. For best +portability, modern implementations should fill the numeric +fields with leading zeros.</p> <p style="margin-left:6%; 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> +(“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><b>•</b></p> <p style="margin-left:17%;">The magic value consists of the -five characters ’’ustar’’ followed -by a space. The version field contains a space character -followed by a null.</p> +five characters “ustar” followed by a space. The +version field contains a space character followed by a +null.</p> <p><b>•</b></p> @@ -273,13 +272,13 @@ archives.</p> <p style="margin-left:6%; 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> +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:14%; margin-top: 1em">struct header_posix_ustar {</p> @@ -432,40 +431,40 @@ header_posix_ustar {</p> the earlier <i>linkflag</i> field with several new type values:</p> -<p>’’0’’</p> +<p>“0”</p> <p style="margin-left:27%; margin-top: 1em">Regular file. NUL should be treated as a synonym, for compatibility purposes.</p> -<p>’’1’’</p> +<p>“1”</p> <p style="margin-left:27%; margin-top: 1em">Hard link.</p> -<p>’’2’’</p> +<p>“2”</p> <p style="margin-left:27%; margin-top: 1em">Symbolic link.</p> -<p>’’3’’</p> +<p>“3”</p> <p style="margin-left:27%; margin-top: 1em">Character device node.</p> -<p>’’4’’</p> +<p>“4”</p> <p style="margin-left:27%; margin-top: 1em">Block device node.</p> -<p>’’5’’</p> +<p>“5”</p> <p style="margin-left:27%; margin-top: 1em">Directory.</p> -<p>’’6’’</p> +<p>“6”</p> <p style="margin-left:27%; margin-top: 1em">FIFO node.</p> -<p>’’7’’</p> +<p>“7”</p> <p style="margin-left:27%; margin-top: 1em">Reserved.</p> @@ -493,16 +492,16 @@ should be set to zero by writers and ignored by readers.</p> <p style="margin-top: 1em"><i>magic</i></p> <p style="margin-left:17%; 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> +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"><i>version</i></p> <p style="margin-left:17%;">Version. This should be -’’00’’ (two copies of the ASCII -digit zero) for POSIX standard archives.</p> +“00” (two copies of the ASCII digit zero) for +POSIX standard archives.</p> <p style="margin-top: 1em"><i>uname</i>, <i>gname</i></p> @@ -589,17 +588,16 @@ implementation.</p> 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> +(“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:6%; margin-top: 1em">An entry in a pax interchange format archive consists of one or two @@ -640,17 +638,16 @@ pax extended attributes are assumed to be in UTF-8, including pathnames, user names, and group names. In some cases, it is not possible to translate local conventions into UTF-8. If this key is present and the value is the -six-character ASCII string -’’BINARY’’, then all textual values -are assumed to be in a platform-dependent multi-byte -encoding. Note that there are only two valid values for this -key: ’’BINARY’’ or -’’ISO-IR 10646 2000 UTF-8’’. -No other values are permitted by the standard, and the -latter value should generally not be used as it is the -default when this key is not specified. In particular, this -flag should not be used as a general mechanism to allow -filenames to be stored in arbitrary encodings.</p> +six-character ASCII string “BINARY”, then all +textual values are assumed to be in a platform-dependent +multi-byte encoding. Note that there are only two valid +values for this key: “BINARY” or +“ISO-IR 10646 2000 UTF-8”. No +other values are permitted by the standard, and the latter +value should generally not be used as it is the default when +this key is not specified. In particular, this flag should +not be used as a general mechanism to allow filenames to be +stored in arbitrary encodings.</p> <p style="margin-top: 1em"><b>uname</b>, <b>uid</b>, <b>gname</b>, <b>gid</b></p> @@ -739,8 +736,8 @@ it.</p> <p style="margin-left:17%;">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.)</p> +“ctime” attribute, which refers to the time when +the file metadata was last changed.)</p> <p style="margin-top: 1em"><b>LIBARCHIVE.xattr.</b><i>namespace</i>.<i>key</i></p> @@ -748,13 +745,11 @@ the time when the file metadata was last changed.)</p> <p style="margin-left:17%;">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> +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"><b>VENDOR.*</b></p> @@ -1137,23 +1132,21 @@ equal to realsize.</p> 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> +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">S</p> <p style="margin-left:27%; 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> +“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">V</p> @@ -1164,16 +1157,15 @@ This entry should generally be ignored on extraction.</p> <p style="margin-top: 1em"><i>magic</i></p> <p style="margin-left:17%; 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> +holds the five characters “ustar” followed by a +space. Note that POSIX ustar archives have a trailing +null.</p> <p style="margin-top: 1em"><i>version</i></p> <p style="margin-left:17%;">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> +use two copies of the ASCII digit “0”.</p> <p style="margin-top: 1em"><i>atime</i>, <i>ctime</i></p> @@ -1200,10 +1192,10 @@ written to the file at appropriate offsets.</p> <p style="margin-top: 1em"><i>isextended</i></p> <p style="margin-left:17%;">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> +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:24%; margin-top: 1em">struct gnu_sparse_header {</p> @@ -1288,52 +1280,49 @@ interchange format archives when you specify the format closely, using some <b>SCHILY</b> tags and introducing 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’’.</p> +referred to as “0.0”, “0.1”, and +“1.0”.</p> <p style="margin-top: 1em"><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:17%;">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-left:17%;">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"><b>GNU.sparse.map</b></p> -<p style="margin-left:17%;">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-left:17%;">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"><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:17%;">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:17%;">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:6%; margin-top: 1em"><b>Solaris Tar</b> <br> @@ -1341,9 +1330,9 @@ XXX More Details Needed XXX</p> <p style="margin-left:6%; 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> +“extended” format that is fundamentally similar +to pax interchange format, with the following +differences:</p> <p><b>•</b></p> @@ -1380,17 +1369,17 @@ Tar</b> <br> 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 additional 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 <b>copyfile</b>() 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 then be put into a tar archive.</p> +“._” prepended to the last path element. This +special file stores an AppleDouble-encoded binary blob with +additional 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 <b>copyfile</b>() 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 then be put into a tar +archive.</p> <p style="margin-left:6%; margin-top: 1em">Note that the Apple extended attributes interact badly with long @@ -1526,11 +1515,11 @@ interchange format per-file extensions.</p> <p style="margin-left:6%;">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> +(“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"><b>HISTORY</b></p> |