Cpio

CPIO(5) FreeBSD File Formats Manual CPIO(5) NAME cpio -- format of cpio archive files DESCRIPTION The cpio archive format collects any number of files, directories, and other file system objects (symbolic links, device nodes, etc.) into a single stream of bytes. General Format Each file system object in a cpio archive comprises a header record with basic numeric metadata followed by the full pathname of the entry and the file data. The header record stores a series of integer values that gen- erally follow the fields in struct stat. (See stat(2) for details.) The variants differ primarily in how they store those integers (binary, octal, or hexadecimal). The header is followed by the pathname of the entry (the length of the pathname is stored in the header) and any file data. The end of the archive is indicated by a special record with the pathname TRAILER!!!''. PWB format XXX Any documentation of the original PWB/UNIX 1.0 format? XXX Old Binary Format The old binary cpio format stores numbers as 2-byte and 4-byte binary values. Each entry begins with a header in the following format: struct header old cpio { unsigned short c magic; unsigned short c dev; unsigned short c ino; unsigned short c mode; unsigned short c uid; unsigned short c gid; unsigned short c nlink; unsigned short c rdev; unsigned short c mtime[2]; unsigned short c namesize; unsigned short c filesize[2]; }; The unsigned short fields here are 16-bit integer values; the unsigned int fields are 32-bit integer values. The fields are as follows magic The integer value octal 070707. This value can be used to deter- mine whether this archive is written with little-endian or big- endian integers. dev, ino The device and inode numbers from the disk. These are used by programs that read cpio archives to determine when two entries refer to the same file. Programs that synthesize cpio archives should be careful to set these to distinct values for each entry. mode The mode specifies both the regular permissions and the file type. It consists of several bit fields as follows: 0170000 This masks the file type bits. 0140000 File type value for sockets. 0120000 File type value for symbolic links. For symbolic links, the link body is stored as file data. 0100000 File type value for regular files. 0060000 File type value for block special devices. 0040000 File type value for directories. 0020000 File type value for character special devices. 0010000 File type value for named pipes or FIFOs. 0004000 SUID bit. 0002000 SGID bit. 0001000 Sticky bit. On some systems, this modifies the behavior of executables and/or directories. 0000777 The lower 9 bits specify read/write/execute permissions for world, group, and user following standard POSIX con- ventions. uid, gid The numeric user id and group id of the owner. nlink The number of links to this file. Directories always have a value of at least two here. Note that hardlinked files include file data with every copy in the archive. rdev For block special and character special entries, this field con- tains the associated device number. For all other entry types, it should be set to zero by writers and ignored by readers. mtime Modification time of the file, indicated as the number of seconds since the start of the epoch, 00:00:00 UTC January 1, 1970. The four-byte integer is stored with the most-significant 16 bits first followed by the least-significant 16 bits. Each of the two 16 bit values are stored in machine-native byte order. namesize The number of bytes in the pathname that follows the header. This count includes the trailing NUL byte. filesize The size of the file. Note that this archive format is limited to four gigabyte file sizes. See mtime above for a description of the storage of four-byte integers. The pathname immediately follows the fixed header. If the namesize is odd, an additional NUL byte is added after the pathname. The file data is then appended, padded with NUL bytes to an even length. Hardlinked files are not give