From b22a4476a66a913a07d5e80334c0400a9b162206 Mon Sep 17 00:00:00 2001 From: Tomas Bzatek Date: Sun, 17 Dec 2023 16:55:58 +0100 Subject: libarchive: Remove in-tree libarchive package Libarchive has become a standard package in most distributions, no need to carry the sources along here. --- .../libarchive-2.8.0/doc/man/libarchive-formats.5 | 341 --------------------- 1 file changed, 341 deletions(-) delete mode 100644 libarchive/libarchive-2.8.0/doc/man/libarchive-formats.5 (limited to 'libarchive/libarchive-2.8.0/doc/man/libarchive-formats.5') diff --git a/libarchive/libarchive-2.8.0/doc/man/libarchive-formats.5 b/libarchive/libarchive-2.8.0/doc/man/libarchive-formats.5 deleted file mode 100644 index ff87c8b..0000000 --- a/libarchive/libarchive-2.8.0/doc/man/libarchive-formats.5 +++ /dev/null @@ -1,341 +0,0 @@ -.TH libarchive-formats 5 "December 27, 2009" "" -.SH NAME -.ad l -\fB\%libarchive-formats\fP -\- archive formats supported by the libarchive library -.SH DESCRIPTION -.ad l -The -\fBlibarchive\fP(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. -.PP -The following provides a brief description of each format supported -by libarchive, with some information about recognized extensions or -limitations 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, though many programs do use libarchive convenience -functions to enable all supported formats. -.SS Tar Formats -The -\fBlibarchive\fP(3) -library can read most tar archives. -However, it only writes POSIX-standard -``ustar'' -and -``pax interchange'' -formats. -.PP -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. -.PP -.RS 5 -.TP -\fBgnutar\fP -The -\fBlibarchive\fP(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. -.TP -\fBpax\fP -The -\fBlibarchive\fP(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 immediately before each regular entry. -The presence of these additional entries 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 Unicode strings. -Keywords defined in the standard are in all lowercase; vendors are allowed -to define custom keys by preceding them with the vendor name in all uppercase. -When writing pax archives, libarchive uses many of the SCHILY keys -defined by Joerg Schilling's -``star'' -archiver and a few LIBARCHIVE keys. -The libarchive library can read most of the SCHILY keys -and most of the GNU keys introduced by GNU tar. -It silently ignores any keywords that it does not understand. -.TP -\fBrestricted\fP pax -The libarchive library can also write pax archives in which it -attempts to suppress the extended attributes entry whenever -possible. -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-compliant pax interchange format archives. -Programs that correctly read ustar format (see below) will also be -able to read this format; any extended attributes will be extracted as -separate files stored in -\fIPaxHeader\fP -directories. -.TP -\fBustar\fP -The libarchive library can both read and write this format. -This format has the following limitations: -.RS 5 -.IP \(bu -Device major and minor numbers are limited to 21 bits. -Nodes with larger numbers will not be added to the archive. -.IP \(bu -Path names in the archive are limited to 255 bytes. -(Shorter if there is no / character in exactly the right place.) -.IP \(bu -Symbolic links and hard links are stored in the archive with -the name of the referenced file. -This name is limited to 100 bytes. -.IP \(bu -Extended attributes, file flags, and other extended -security information cannot be stored. -.IP \(bu -Archive entries are limited to 8 gigabytes in size. -.RE -Note that the pax interchange format has none of these restrictions. -.RE -.PP -The libarchive library also reads a variety of commonly-used extensions to -the basic tar format. -These extensions are recognized automatically whenever they appear. -.RS 5 -.TP -Numeric extensions. -The POSIX standards require fixed-length numeric fields to be written with -some character position reserved for terminators. -Libarchive allows these fields to be written without terminator characters. -This extends the allowable range; in particular, ustar archives with this -extension can support entries up to 64 gigabytes in size. -Libarchive also recognizes base-256 values in most numeric fields. -This essentially removes all limitations on file size, modification time, -and device numbers. -.TP -Solaris extensions -Libarchive recognizes ACL and extended attribute records written -by Solaris tar. -Currently, libarchive only has support for old-style ACLs; the -newer NFSv4 ACLs are recognized but discarded. -.RE -.PP -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. -.SS 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 the tar format, the cpio format does only minimal padding -of the header or file data. -There are several cpio variants, 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. -.RS 5 -.TP -\fBbinary\fP -The libarchive library transparently reads 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. -.TP -\fBodc\fP -The libarchive library can both read and write this -POSIX-standard format, which is officially known as the -``cpio interchange format'' -or the -``octet-oriented cpio archive format'' -and sometimes unofficially referred to as the -``old character 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. -.TP -\fBSVR4\fP -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. -.RE -.PP -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 -\fB\%find\fP -and -\fB\%cpio\fP -utilities provided very precise control over file selection. -Unfortunately, the format has many limitations 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 dissimilar user numbering. -.SS Shar Formats -A -``shell archive'' -is a shell script that, when executed on a POSIX-compliant -system, will recreate a collection of file system objects. -The libarchive library can write two different kinds of shar archives: -.RS 5 -.TP -\fBshar\fP -The traditional shar format uses a limited set of POSIX -commands, including -\fBecho\fP(1), -\fBmkdir\fP(1), -and -\fBsed\fP(1). -It is suitable for portably archiving small collections of plain text files. -However, it is not generally well-suited for large archives -(many implementations of -\fBsh\fP(1) -have limits on the size of a script) nor should it be used with non-text files. -.TP -\fBshardump\fP -This format is similar to shar but encodes files using -\fBuuencode\fP(1) -so that the result will be a plain text file regardless 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 commands used to restore file attributes make -shardump archives less portable than plain shar archives. -.RE -.SS ISO9660 format -Libarchive can read and extract from files containing ISO9660-compliant -CDROM images. -In many cases, this can remove the need to burn a physical CDROM -just in order to read the files contained in an ISO9660 image. -It also avoids security and complexity issues that come with -virtual mounts and loopback devices. -Libarchive supports the most common Rockridge extensions and has partial -support for Joliet extensions. -If both extensions are present, the Joliet extensions will be -used and the Rockridge extensions will be ignored. -In particular, this can create problems with hardlinks and symlinks, -which are supported by Rockridge but not by Joliet. -.SS Zip format -Libarchive can read and write zip format archives that have -uncompressed entries and entries compressed with the -``deflate'' -algorithm. -Older zip compression algorithms are not supported. -It can extract jar archives, archives that use Zip64 extensions and many -self-extracting zip archives. -Libarchive reads Zip archives as they are being streamed, -which allows it to read archives of arbitrary size. -It currently does not use the central directory; this -limits libarchive's ability to support some self-extracting -archives and ones that have been modified in certain ways. -.SS Archive (library) file format -The Unix archive format (commonly created by the -\fBar\fP(1) -archiver) is a general-purpose format which is -used almost exclusively for object files to be -read by the link editor -\fBld\fP(1). -The ar format has never been standardised. -There are two common variants: -the GNU format derived from SVR4, -and the BSD format, which first appeared in 4.4BSD. -The two differ primarily in their handling of filenames -longer than 15 characters: -the GNU/SVR4 variant writes a filename table at the beginning of the archive; -the BSD format stores each long filename in an extension -area adjacent to the entry. -Libarchive can read both extensions, -including archives that may include both types of long filenames. -Programs using libarchive can write GNU/SVR4 format -if they provide a filename table to be written into -the archive before any of the entries. -Any entries whose names are not in the filename table -will be written using BSD-style long filenames. -This can cause problems for programs such as -GNU ld that do not support the BSD-style long filenames. -.SS mtree -Libarchive can read and write files in -\fBmtree\fP(5) -format. -This format is not a true archive format, but rather a textual description -of a file hierarchy in which each line specifies the name of a file and -provides specific metadata about that file. -Libarchive can read all of the keywords supported by both -the NetBSD and FreeBSD versions of -\fBmtree\fP(1), -although many of the keywords cannot currently be stored in an -Tn archive_entry -object. -When writing, libarchive supports use of the -\fBarchive_write_set_options\fP(3) -interface to specify which keywords should be included in the -output. -If libarchive was compiled with access to suitable -cryptographic libraries (such as the OpenSSL libraries), -it can compute hash entries such as -\fBsha512\fP -or -\fBmd5\fP -from file data being written to the mtree writer. -.PP -When reading an mtree file, libarchive will locate the corresponding -files on disk using the -\fBcontents\fP -keyword if present or the regular filename. -If it can locate and open the file on disk, it will use that -to fill in any metadata that is missing from the mtree file -and will read the file contents and return those to the program -using libarchive. -If it cannot locate and open the file on disk, libarchive -will return an error for any attempt to read the entry -body. -.SH SEE ALSO -.ad l -\fBar\fP(1), -\fBcpio\fP(1), -\fBmkisofs\fP(1), -\fBshar\fP(1), -\fBtar\fP(1), -\fBzip\fP(1), -\fBzlib\fP(3), -\fBcpio\fP(5), -\fBmtree\fP(5), -\fBtar\fP(5) -- cgit v1.2.3