1.\" Copyright (c) 2003-2007 Tim Kientzle 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 13.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 14.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 15.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 16.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 17.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 18.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 19.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 20.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 21.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 22.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 23.\" SUCH DAMAGE. 24.\" 25.\" $FreeBSD: src/lib/libarchive/libarchive-formats.5,v 1.16 2008/05/26 17:00:23 kientzle Exp $ 26.\" 27.Dd April 27, 2004 28.Dt libarchive-formats 3 29.Os 30.Sh NAME 31.Nm libarchive-formats 32.Nd archive formats supported by the libarchive library 33.Sh DESCRIPTION 34The 35.Xr libarchive 3 36library reads and writes a variety of streaming archive formats. 37Generally speaking, all of these archive formats consist of a series of 38.Dq entries . 39Each entry stores a single file system object, such as a file, directory, 40or symbolic link. 41.Pp 42The following provides a brief description of each format supported 43by libarchive, with some information about recognized extensions or 44limitations of the current library support. 45Note that just because a format is supported by libarchive does not 46imply that a program that uses libarchive will support that format. 47Applications that use libarchive specify which formats they wish 48to support. 49.Ss Tar Formats 50The 51.Xr libarchive 3 52library can read most tar archives. 53However, it only writes POSIX-standard 54.Dq ustar 55and 56.Dq pax interchange 57formats. 58.Pp 59All tar formats store each entry in one or more 512-byte records. 60The first record is used for file metadata, including filename, 61timestamp, and mode information, and the file data is stored in 62subsequent records. 63Later variants have extended this by either appropriating undefined 64areas of the header record, extending the header to multiple records, 65or by storing special entries that modify the interpretation of 66subsequent entries. 67.Pp 68.Bl -tag -width indent 69.It Cm gnutar 70The 71.Xr libarchive 3 72library can read GNU-format tar archives. 73It currently supports the most popular GNU extensions, including 74modern long filename and linkname support, as well as atime and ctime data. 75The libarchive library does not support multi-volume 76archives, nor the old GNU long filename format. 77It can read GNU sparse file entries, including the new POSIX-based 78formats, but cannot write GNU sparse file entries. 79.It Cm pax 80The 81.Xr libarchive 3 82library can read and write POSIX-compliant pax interchange format 83archives. 84Pax interchange format archives are an extension of the older ustar 85format that adds a separate entry with additional attributes stored 86as key/value pairs. 87The presence of this additional entry is the only difference between 88pax interchange format and the older ustar format. 89The extended attributes are of unlimited length and are stored 90as UTF-8 Unicode strings. 91Keywords defined in the standard are in all lowercase; vendors are allowed 92to define custom keys by preceding them with the vendor name in all uppercase. 93When writing pax archives, libarchive uses many of the SCHILY keys 94defined by Joerg Schilling's 95.Dq star 96archiver. 97The libarchive library can read most of the SCHILY keys. 98It silently ignores any keywords that it does not understand. 99.It Cm restricted pax 100The libarchive library can also write pax archives in which it 101attempts to suppress the extended attributes entry whenever 102possible. 103The result will be identical to a ustar archive unless the 104extended attributes entry is required to store a long file 105name, long linkname, extended ACL, file flags, or if any of the standard 106ustar data (user name, group name, UID, GID, etc) cannot be fully 107represented in the ustar header. 108In all cases, the result can be dearchived by any program that 109can read POSIX-compliant pax interchange format archives. 110Programs that correctly read ustar format (see below) will also be 111able to read this format; any extended attributes will be extracted as 112separate files stored in 113.Pa PaxHeader 114directories. 115.It Cm ustar 116The libarchive library can both read and write this format. 117This format has the following limitations: 118.Bl -bullet -compact 119.It 120Device major and minor numbers are limited to 21 bits. 121Nodes with larger numbers will not be added to the archive. 122.It 123Path names in the archive are limited to 255 bytes. 124(Shorter if there is no / character in exactly the right place.) 125.It 126Symbolic links and hard links are stored in the archive with 127the name of the referenced file. 128This name is limited to 100 bytes. 129.It 130Extended attributes, file flags, and other extended 131security information cannot be stored. 132.It 133Archive entries are limited to 2 gigabytes in size. 134.El 135Note that the pax interchange format has none of these restrictions. 136.El 137.Pp 138The libarchive library can also read a variety of commonly-used extensions to 139the basic tar format. 140In particular, it supports base-256 values in certain numeric fields. 141This essentially removes the limitations on file size, modification time, 142and device numbers. 143.Pp 144The first tar program appeared in Seventh Edition Unix in 1979. 145The first official standard for the tar file format was the 146.Dq ustar 147(Unix Standard Tar) format defined by POSIX in 1988. 148POSIX.1-2001 extended the ustar format to create the 149.Dq pax interchange 150format. 151.Ss Cpio Formats 152The libarchive library can read a number of common cpio variants and can write 153.Dq odc 154and 155.Dq newc 156format archives. 157A cpio archive stores each entry as a fixed-size header followed 158by a variable-length filename and variable-length data. 159Unlike tar, cpio does only minimal padding of the header or file data. 160There are a variety of cpio formats, which differ primarily in 161how they store the initial header: some store the values as 162octal or hexadecimal numbers in ASCII, others as binary values of 163varying byte order and length. 164.Bl -tag -width indent 165.It Cm binary 166The libarchive library can read both big-endian and little-endian 167variants of the original binary cpio format. 168This format used 32-bit binary values for file size and mtime, 169and 16-bit binary values for the other fields. 170.It Cm odc 171The libarchive library can both read and write this 172POSIX-standard format. 173This format stores the header contents as octal values in ASCII. 174It is standard, portable, and immune from byte-order confusion. 175File sizes and mtime are limited to 33 bits (8GB file size), 176other fields are limited to 18 bits. 177.It Cm SVR4 178The libarchive library can read both CRC and non-CRC variants of 179this format. 180The SVR4 format uses eight-digit hexadecimal values for 181all header fields. 182This limits file size to 4GB, and also limits the mtime and 183other fields to 32 bits. 184The SVR4 format can optionally include a CRC of the file 185contents, although libarchive does not currently verify this CRC. 186.El 187.Pp 188Cpio first appeared in PWB/UNIX 1.0, which was released within 189AT&T in 1977. 190PWB/UNIX 1.0 formed the basis of System III Unix, released outside 191of AT&T in 1981. 192This makes cpio older than tar, although cpio was not included 193in Version 7 AT&T Unix. 194As a result, the tar command became much better known in universities 195and research groups that used Version 7. 196The combination of the 197.Nm find 198and 199.Nm cpio 200utilities provided very precise control over file selection. 201Unfortunately, the format has many limitations that make it unsuitable 202for widespread use. 203Only the POSIX format permits files over 4GB, and its 18-bit 204limit for most other fields makes it unsuitable for modern systems. 205In addition, cpio formats only store numeric UID/GID values (not 206usernames and group names), which can make it very difficult to correctly 207transfer archives across systems with dissimilar user numbering. 208.Ss Shar Formats 209A 210.Dq shell archive 211is a shell script that, when executed on a POSIX-compliant 212system, will recreate a collection of file system objects. 213The libarchive library can write two different kinds of shar archives: 214.Bl -tag -width indent 215.It Cm shar 216The traditional shar format uses a limited set of POSIX 217commands, including 218.Xr echo 1 , 219.Xr mkdir 1 , 220and 221.Xr sed 1 . 222It is suitable for portably archiving small collections of plain text files. 223However, it is not generally well-suited for large archives 224(many implementations of 225.Xr sh 1 226have limits on the size of a script) nor should it be used with non-text files. 227.It Cm shardump 228This format is similar to shar but encodes files using 229.Xr uuencode 1 230so that the result will be a plain text file regardless of the file contents. 231It also includes additional shell commands that attempt to reproduce as 232many file attributes as possible, including owner, mode, and flags. 233The additional commands used to restore file attributes make 234shardump archives less portable than plain shar archives. 235.El 236.Ss ISO9660 format 237Libarchive can read and extract from files containing ISO9660-compliant 238CDROM images. 239It also has partial support for Rockridge extensions. 240In many cases, this can remove the need to burn a physical CDROM. 241It also avoids security and complexity issues that come with 242virtual mounts and loopback devices. 243.Ss Zip format 244Libarchive can extract from most zip format archives. 245It currently only supports uncompressed entries and entries 246compressed with the 247.Dq deflate 248algorithm. 249Older zip compression algorithms are not supported. 250.Ss Archive (library) file format 251The Unix archive format (commonly created by the 252.Xr ar 1 253archiver) is a general-purpose format which is 254used almost exclusively for object files to be 255read by the link editor 256.Xr ld 1 . 257The ar format has never been standardised. 258There are two common variants: 259the GNU format derived from SVR4, 260and the BSD format, which first appeared in 4.4BSD. 261Libarchive provides read and write support for both variants. 262.Ss mtree 263Libarchive can read files in 264.Xr mtree 5 265format. This format is not a true archive format, but rather a description 266of a file hierarchy. When requested, libarchive obtains the contents of 267the files described by the 268.Xr mtree 5 269format from files on disk instead. 270.Sh SEE ALSO 271.Xr ar 1 , 272.Xr cpio 1 , 273.Xr mkisofs 1 , 274.Xr shar 1 , 275.Xr tar 1 , 276.Xr zip 1 , 277.Xr zlib 3 , 278.Xr cpio 5 , 279.Xr mtree 5 , 280.Xr tar 5 281