diff options
Diffstat (limited to 'archivers/libarchive/files/doc/text/tar.5.txt')
| -rw-r--r-- | archivers/libarchive/files/doc/text/tar.5.txt | 42 |
1 files changed, 21 insertions, 21 deletions
diff --git a/archivers/libarchive/files/doc/text/tar.5.txt b/archivers/libarchive/files/doc/text/tar.5.txt index eec362e890d..f806f6664dc 100644 --- a/archivers/libarchive/files/doc/text/tar.5.txt +++ b/archivers/libarchive/files/doc/text/tar.5.txt @@ -1,4 +1,4 @@ -tar(5) NetBSD File Formats Manual tar(5) +tar(5) FreeBSD File Formats Manual tar(5) NAME tar -- format of tape archive files @@ -63,9 +63,9 @@ DESCRIPTION User id and group id of owner, as octal numbers in ASCII. size Size of file, as octal number in ASCII. For regular files only, - this indicates the amount of data that follows the header. In + 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 + when extracting hardlinks. Modern writers should always store a zero length for hardlink entries. mtime Modification time of file, as an octal number in ASCII. This @@ -78,7 +78,7 @@ DESCRIPTION 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 + character. Note that many early implementations of tar used signed arithmetic for the checksum field, which can cause inter- operability problems when transferring archives between systems. Modern robust readers compute the checksum both ways and accept @@ -108,11 +108,11 @@ DESCRIPTION for John Gilmore's pdtar 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: - The magic value is ``ustar '' (note the following space). The + o The magic value is ``ustar '' (note the following space). The version field contains a space character followed by a null. - The numeric fields are generally filled with leading spaces (not + o The numeric fields are generally filled with leading spaces (not leading zeros as recommended in the final standard). - The prefix field is often not used, limiting pathnames to the 100 + o The prefix field is often not used, limiting pathnames to the 100 characters of old-style archives. POSIX ustar Archives @@ -189,7 +189,7 @@ DESCRIPTION name, prefix If the pathname is too long to fit in the 100 bytes provided by the standard format, it can be split at any / character with the - first portion going into the prefix field. If the prefix field + first portion going into the prefix field. If the prefix field is not empty, the reader will prepend the prefix value and a / character to the regular name field to obtain the full pathname. The standard does not require a trailing / character on directory @@ -240,7 +240,7 @@ DESCRIPTION mal, not octal. A description of some common keys follows: atime, ctime, mtime - File access, inode change, and modification times. These fields + File access, inode change, and modification times. These fields can be negative or include a decimal point and a fractional value. @@ -285,7 +285,7 @@ DESCRIPTION The file flags. SCHILY.realsize - The full size of the file on disk. XXX explain? XXX + The full size of the file on disk. XXX explain? XXX SCHILY.dev, SCHILY.ino, SCHILY.nlinks The device number, inode number, and link count for the entry. @@ -310,7 +310,7 @@ DESCRIPTION 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 arbitrar- - ily large. All text fields are encoded in UTF8. Compliant writers + ily 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. @@ -431,7 +431,7 @@ DESCRIPTION tax. Due to security concerns, "N" records are now gen- erally ignored when reading archives. - S This is a ``sparse'' regular file. Sparse files are + S 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 nec- @@ -476,8 +476,8 @@ DESCRIPTION char offset[12]; char numbytes[12]; } sparse[21]; - char isextended[1]; - char padding[7]; + char isextended[1]; + char padding[7]; }; realsize @@ -490,7 +490,7 @@ DESCRIPTION GNU tar pax archives GNU tar 1.14 (XXX check this XXX) and later will write pax interchange - format archives when you specify the --posix flag. This format uses cus- + format archives when you specify the --posix flag. This format uses cus- tom keywords to store sparse file information. There have been three iterations of this support, referred to as ``0.0'', ``0.1'', and ``1.0''. @@ -500,7 +500,7 @@ DESCRIPTION to indicate the number of blocks in the file, a pair of GNU.sparse.offset and GNU.sparse.numbytes to indicate the offset and size of each block, and a single GNU.sparse.size to indicate - the full size of the file. This is not the same as the size in + 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 @@ -509,7 +509,7 @@ DESCRIPTION GNU.sparse.map The ``0.1'' format used a single attribute that stored a comma- - separated list of decimal numbers. Each pair of numbers indi- + separated list of decimal numbers. Each pair of numbers indi- cated 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 @@ -531,11 +531,11 @@ DESCRIPTION Solaris tar (beginning with SunOS XXX 5.7 ?? XXX) supports an ``extended'' format that is fundamentally similar to pax interchange for- mat, with the following differences: - Extended attributes are stored in an entry whose type is X, not + o Extended attributes are stored in an entry whose type is X, not x, as used by pax interchange format. The detailed format of this entry appears to be the same as detailed above for the x entry. - An additional A entry is used to store an ACL for the following + o An additional A 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 @@ -562,7 +562,7 @@ DESCRIPTION allows file sizes up to 64 GB. Another extension, utilized by GNU tar, star, and other newer tar imple- - mentations, permits binary numbers in the standard numeric fields. This + mentations, 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 @@ -598,4 +598,4 @@ HISTORY This documentation was written as part of the libarchive and bsdtar project by Tim Kientzle <kientzle@FreeBSD.org>. -NetBSD 5.0 December 27, 2009 NetBSD 5.0 +FreeBSD 9.0 December 27, 2009 FreeBSD 9.0 |