diff options
Diffstat (limited to 'libarchive/libarchive-2.4.17/doc/text/libarchive-formats.5')
| -rw-r--r-- | libarchive/libarchive-2.4.17/doc/text/libarchive-formats.5 | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/libarchive/libarchive-2.4.17/doc/text/libarchive-formats.5 b/libarchive/libarchive-2.4.17/doc/text/libarchive-formats.5 new file mode 100644 index 0000000..35eb278 --- /dev/null +++ b/libarchive/libarchive-2.4.17/doc/text/libarchive-formats.5 @@ -0,0 +1,180 @@ +libarchive-formats(3) FreeBSD Library Functions Manual libarchive-formats(3) + +NAME + libarchive-formats -- archive formats supported by the libarchive library + +DESCRIPTION + The libarchive(3) library reads and writes a variety of streaming archive + formats. Generally speaking, all of these archive formats consist of a + series of ``entries''. Each entry stores a single file system object, + such as a file, directory, or symbolic link. + + The following provides a brief description of each format supported by + libarchive, with some information about recognized extensions or limita- + tions of the current library support. Note that just because a format is + supported by libarchive does not imply that a program that uses + libarchive will support that format. Applications that use libarchive + specify which formats they wish to support. + + Tar Formats + The libarchive(3) library can read most tar archives. However, it only + writes POSIX-standard ``ustar'' and ``pax interchange'' formats. + + All tar formats store each entry in one or more 512-byte records. The + first record is used for file metadata, including filename, timestamp, + and mode information, and the file data is stored in subsequent records. + Later variants have extended this by either appropriating undefined areas + of the header record, extending the header to multiple records, or by + storing special entries that modify the interpretation of subsequent + entries. + + gnutar The libarchive(3) library can read GNU-format tar archives. It + currently supports the most popular GNU extensions, including + modern long filename and linkname support, as well as atime and + ctime data. The libarchive library does not support multi-volume + archives, nor the old GNU long filename format. It can read GNU + sparse file entries, including the new POSIX-based formats, but + cannot write GNU sparse file entries. + + pax The libarchive(3) library can read and write POSIX-compliant pax + interchange format archives. Pax interchange format archives are + an extension of the older ustar format that adds a separate entry + with additional attributes stored as key/value pairs. The pres- + ence of this additional entry is the only difference between pax + interchange format and the older ustar format. The extended + attributes are of unlimited length and are stored as UTF-8 Uni- + code strings. Keywords defined in the standard are in all lower- + case; vendors are allowed to define custom keys by preceding them + with the vendor name in all uppercase. When writing pax ar- + chives, libarchive uses many of the SCHILY keys defined by Joerg + Schilling's ``star'' archiver. The libarchive library can read + most of the SCHILY keys. It silently ignores any keywords that + it does not understand. + + restricted pax + The libarchive library can also write pax archives in which it + attempts to suppress the extended attributes entry whenever pos- + sible. The result will be identical to a ustar archive unless + the extended attributes entry is required to store a long file + name, long linkname, extended ACL, file flags, or if any of the + standard ustar data (user name, group name, UID, GID, etc) cannot + be fully represented in the ustar header. In all cases, the + result can be dearchived by any program that can read POSIX-com- + pliant pax interchange format archives. Programs that correctly + read ustar format (see below) will also be able to read this for- + mat; any extended attributes will be extracted as separate files + stored in PaxHeader directories. + + ustar The libarchive library can both read and write this format. This + format has the following limitations: + o Device major and minor numbers are limited to 21 bits. Nodes + with larger numbers will not be added to the archive. + o Path names in the archive are limited to 255 bytes. (Shorter + if there is no / character in exactly the right place.) + o Symbolic links and hard links are stored in the archive with + the name of the referenced file. This name is limited to 100 + bytes. + o Extended attributes, file flags, and other extended security + information cannot be stored. + o Archive entries are limited to 2 gigabytes in size. + Note that the pax interchange format has none of these restric- + tions. + + The libarchive library can also read a variety of commonly-used exten- + sions to the basic tar format. In particular, it supports base-256 val- + ues in certain numeric fields. This essentially removes the limitations + on file size, modification time, and device numbers. + + The first tar program appeared in Seventh Edition Unix in 1979. The + first official standard for the tar file format was the ``ustar'' (Unix + Standard Tar) format defined by POSIX in 1988. POSIX.1-2001 extended the + ustar format to create the ``pax interchange'' format. + + Cpio Formats + The libarchive library can read a number of common cpio variants and can + write ``odc'' and ``newc'' format archives. A cpio archive stores each + entry as a fixed-size header followed by a variable-length filename and + variable-length data. Unlike tar, cpio does only minimal padding of the + header or file data. There are a variety of cpio formats, which differ + primarily in how they store the initial header: some store the values as + octal or hexadecimal numbers in ASCII, others as binary values of varying + byte order and length. + + binary The libarchive library can read both big-endian and little-endian + variants of the original binary cpio format. This format used + 32-bit binary values for file size and mtime, and 16-bit binary + values for the other fields. + + odc The libarchive library can both read and write this POSIX-stan- + dard format. This format stores the header contents as octal + values in ASCII. It is standard, portable, and immune from byte- + order confusion. File sizes and mtime are limited to 33 bits + (8GB file size), other fields are limited to 18 bits. + + SVR4 The libarchive library can read both CRC and non-CRC variants of + this format. The SVR4 format uses eight-digit hexadecimal values + for all header fields. This limits file size to 4GB, and also + limits the mtime and other fields to 32 bits. The SVR4 format + can optionally include a CRC of the file contents, although + libarchive does not currently verify this CRC. + + Cpio first appeared in PWB/UNIX 1.0, which was released within AT&T in + 1977. PWB/UNIX 1.0 formed the basis of System III Unix, released outside + of AT&T in 1981. This makes cpio older than tar, although cpio was not + included in Version 7 AT&T Unix. As a result, the tar command became + much better known in universities and research groups that used Version + 7. The combination of the find and cpio utilities provided very precise + control over file selection. Unfortunately, the format has many limita- + tions that make it unsuitable for widespread use. Only the POSIX format + permits files over 4GB, and its 18-bit limit for most other fields makes + it unsuitable for modern systems. In addition, cpio formats only store + numeric UID/GID values (not usernames and group names), which can make it + very difficult to correctly transfer archives across systems with dissim- + ilar user numbering. + + Shar Formats + A ``shell archive'' is a shell script that, when executed on a POSIX-com- + pliant system, will recreate a collection of file system objects. The + libarchive library can write two different kinds of shar archives: + + shar The traditional shar format uses a limited set of POSIX commands, + including echo(1), mkdir(1), and sed(1). It is suitable for + portably archiving small collections of plain text files. How- + ever, it is not generally well-suited for large archives (many + implementations of sh(1) have limits on the size of a script) nor + should it be used with non-text files. + + shardump + This format is similar to shar but encodes files using + uuencode(1) so that the result will be a plain text file regard- + less of the file contents. It also includes additional shell + commands that attempt to reproduce as many file attributes as + possible, including owner, mode, and flags. The additional com- + mands used to restore file attributes make shardump archives less + portable than plain shar archives. + + ISO9660 format + Libarchive can read and extract from files containing ISO9660-compliant + CDROM images. It also has partial support for Rockridge extensions. In + many cases, this can remove the need to burn a physical CDROM. It also + avoids security and complexity issues that come with virtual mounts and + loopback devices. + + Zip format + Libarchive can extract from most zip format archives. It currently only + supports uncompressed entries and entries compressed with the ``deflate'' + algorithm. Older zip compression algorithms are not supported. + + Archive (library) file format + The Unix archive format (commonly created by the ar(1) archiver) is a + general-purpose format which is used almost exclusively for object files + to be read by the link editor ld(1). The ar format has never been stan- + dardised. There are two common variants: the GNU format derived from + SVR4, and the BSD format, which first appeared in 4.4BSD. Libarchive + provides read and write support for both variants. + +SEE ALSO + ar(1), cpio(1), mkisofs(1), shar(1), tar(1), zip(1), zlib(3), cpio(5), + mtree(5), tar(5) + +FreeBSD 6.0 April 27, 2004 FreeBSD 6.0 |