diff options
| author | joerg <joerg@pkgsrc.org> | 2017-08-01 22:21:09 +0000 |
|---|---|---|
| committer | joerg <joerg@pkgsrc.org> | 2017-08-01 22:21:09 +0000 |
| commit | 8ebf4e7079542370a0dd5eba7eed1790d20c7f96 (patch) | |
| tree | 3c71484d8e555935fd266acfd45eff3b04d0f139 /archivers/libarchive/files/doc/html/tar.5.html | |
| parent | c8fcd52665c6781876ed54832bd7f6ea46348688 (diff) | |
| download | pkgsrc-8ebf4e7079542370a0dd5eba7eed1790d20c7f96.tar.gz | |
Import libarchive-3.3.2 + 9de5f3 + f9dacbf:
- Support NFS4 ACLs on Linux
- Bugfixes
Diffstat (limited to 'archivers/libarchive/files/doc/html/tar.5.html')
| -rw-r--r-- | archivers/libarchive/files/doc/html/tar.5.html | 111 |
1 files changed, 55 insertions, 56 deletions
diff --git a/archivers/libarchive/files/doc/html/tar.5.html b/archivers/libarchive/files/doc/html/tar.5.html index 692a7993167..2e0969b9dbb 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: Sat Feb 25 11:22:08 2017 --> +<!-- CreationDate: Mon Jul 10 02:32:58 2017 --> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> @@ -50,14 +50,14 @@ 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 +’’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 +’’block’’ and +’’record’’ here are not entirely standard; this document follows the convention established by John Gilmore in documenting <b>pdtar</b>.)</p> @@ -224,7 +224,7 @@ matches.</p> 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 +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> @@ -239,14 +239,14 @@ 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. +(’’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 +(’’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 @@ -255,7 +255,7 @@ 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 +five characters ’’ustar’’ followed by a space. The version field contains a space character followed by a null.</p> @@ -273,12 +273,12 @@ archives.</p> <p style="margin-left:6%; margin-top: 1em"><b>POSIX ustar Archives</b> <br> -IEEE Std 1003.1-1988 (‘‘POSIX.1’’) +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 +called the ’’ustar’’ format, after the magic value used in the header. (The name is an acronym -for ‘‘Unix Standard TAR’’.) It +for ’’Unix Standard TAR’’.) It extends the historic format with new fields:</p> <p style="margin-left:14%; margin-top: 1em">struct @@ -432,40 +432,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,7 +493,7 @@ 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 +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> @@ -501,7 +501,7 @@ 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 +’’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,14 +589,14 @@ 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 +(’’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 +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> @@ -641,11 +641,11 @@ 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 +’’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’’. +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 @@ -739,7 +739,7 @@ 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 +’’ctime’’ attribute, which refers to the time when the file metadata was last changed.)</p> @@ -749,9 +749,9 @@ the time when the file metadata was last changed.)</p> 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 +’’=’’ 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> @@ -1137,8 +1137,8 @@ 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 +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 @@ -1147,13 +1147,13 @@ archives.</p> <p style="margin-top: 1em">S</p> <p style="margin-left:27%; margin-top: 1em">This is a -‘‘sparse’’ regular file. Sparse +’’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 +as necessary with ’’extra’’ header extensions (an older format that is no longer used), or -‘‘sparse’’ extensions.</p> +’’sparse’’ extensions.</p> <p style="margin-top: 1em">V</p> @@ -1164,7 +1164,7 @@ 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’’ +holds the five characters ’’ustar’’ followed by a space. Note that POSIX ustar archives have a trailing null.</p> @@ -1173,7 +1173,7 @@ trailing null.</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> +’’0’’.</p> <p style="margin-top: 1em"><i>atime</i>, <i>ctime</i></p> @@ -1200,7 +1200,7 @@ 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 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> @@ -1284,21 +1284,20 @@ total size of the file.</p> 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 follows the pax -interchange 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> +<b>--posix</b> flag. This format follows the pax interchange +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> <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 +’’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 @@ -1313,7 +1312,7 @@ 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 +’’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 @@ -1326,7 +1325,7 @@ simply discard unrecognized attributes.</p> <b>GNU.sparse.realsize</b></p> <p style="margin-left:17%;">The -‘‘1.0’’ format stores the sparse +’’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 @@ -1342,7 +1341,7 @@ 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 +’’extended’’ format that is fundamentally similar to pax interchange format, with the following differences:</p> @@ -1381,7 +1380,7 @@ 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 +’’._’’ 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 @@ -1389,7 +1388,7 @@ 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 +’’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> @@ -1527,11 +1526,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 +(’’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> +1003.1-2001 (’’POSIX.1’’).</p> <p style="margin-top: 1em"><b>HISTORY</b></p> |