mirror of
https://github.com/cmclark00/retro-imager.git
synced 2025-05-19 16:35:20 +01:00
415 lines
13 KiB
HTML
415 lines
13 KiB
HTML
<!-- Creator : groff version 1.22.3 -->
|
|
<!-- CreationDate: Tue Feb 11 22:58:46 2020 -->
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="groff -Thtml, see www.gnu.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
|
|
<meta name="Content-Style" content="text/css">
|
|
<style type="text/css">
|
|
p { margin-top: 0; margin-bottom: 0; vertical-align: top }
|
|
pre { margin-top: 0; margin-bottom: 0; vertical-align: top }
|
|
table { margin-top: 0; margin-bottom: 0; vertical-align: top }
|
|
h1 { text-align: center }
|
|
</style>
|
|
<title></title>
|
|
</head>
|
|
<body>
|
|
|
|
<hr>
|
|
|
|
|
|
<p>CPIO(5) BSD File Formats Manual CPIO(5)</p>
|
|
|
|
<p style="margin-top: 1em"><b>NAME</b></p>
|
|
|
|
<p style="margin-left:6%;"><b>cpio</b> — format of
|
|
cpio archive files</p>
|
|
|
|
<p style="margin-top: 1em"><b>DESCRIPTION</b></p>
|
|
|
|
<p style="margin-left:6%;">The <b>cpio</b> archive format
|
|
collects any number of files, directories, and other file
|
|
system objects (symbolic links, device nodes, etc.) into a
|
|
single stream of bytes.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>General
|
|
Format</b> <br>
|
|
Each file system object in a <b>cpio</b> 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 generally
|
|
follow the fields in <i>struct stat</i>. (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!!!’’.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>PWB
|
|
format</b> <br>
|
|
XXX Any documentation of the original PWB/UNIX 1.0 format?
|
|
XXX</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>Old Binary
|
|
Format</b> <br>
|
|
The old binary <b>cpio</b> format stores numbers as 2-byte
|
|
and 4-byte binary values. Each entry begins with a header in
|
|
the following format:</p>
|
|
|
|
<p style="margin-left:14%; margin-top: 1em">struct
|
|
header_old_cpio { <br>
|
|
unsigned short c_magic; <br>
|
|
unsigned short c_dev; <br>
|
|
unsigned short c_ino; <br>
|
|
unsigned short c_mode; <br>
|
|
unsigned short c_uid; <br>
|
|
unsigned short c_gid; <br>
|
|
unsigned short c_nlink; <br>
|
|
unsigned short c_rdev;</p>
|
|
|
|
<table width="100%" border="0" rules="none" frame="void"
|
|
cellspacing="0" cellpadding="0">
|
|
<tr valign="top" align="left">
|
|
<td width="24%"></td>
|
|
<td width="11%">
|
|
|
|
|
|
<p>unsigned short c_mtime[2];</p></td>
|
|
<td width="65%">
|
|
</td></tr>
|
|
</table>
|
|
|
|
<p style="margin-left:14%;">unsigned short c_namesize;</p>
|
|
|
|
<table width="100%" border="0" rules="none" frame="void"
|
|
cellspacing="0" cellpadding="0">
|
|
<tr valign="top" align="left">
|
|
<td width="24%"></td>
|
|
<td width="76%">
|
|
|
|
|
|
<p>unsigned short c_filesize[2];</p></td></tr>
|
|
</table>
|
|
|
|
<p style="margin-left:14%;">};</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The <i>unsigned
|
|
short</i> fields here are 16-bit integer values; the
|
|
<i>unsigned int</i> fields are 32-bit integer values. The
|
|
fields are as follows</p>
|
|
|
|
<p style="margin-top: 1em"><i>magic</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">The integer
|
|
value octal 070707. This value can be used to determine
|
|
whether this archive is written with little-endian or
|
|
big-endian integers.</p>
|
|
|
|
<p style="margin-top: 1em"><i>dev</i>, <i>ino</i></p>
|
|
|
|
<p style="margin-left:17%;">The device and inode numbers
|
|
from the disk. These are used by programs that read
|
|
<b>cpio</b> archives to determine when two entries refer to
|
|
the same file. Programs that synthesize <b>cpio</b> archives
|
|
should be careful to set these to distinct values for each
|
|
entry.</p>
|
|
|
|
<p style="margin-top: 1em"><i>mode</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">The mode
|
|
specifies both the regular permissions and the file type. It
|
|
consists of several bit fields as follows:</p>
|
|
|
|
<p>0170000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">This masks the
|
|
file type bits.</p>
|
|
|
|
<p>0140000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for sockets.</p>
|
|
|
|
<p>0120000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for symbolic links. For symbolic links, the link body is
|
|
stored as file data.</p>
|
|
|
|
<p>0100000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for regular files.</p>
|
|
|
|
<p>0060000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for block special devices.</p>
|
|
|
|
<p>0040000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for directories.</p>
|
|
|
|
<p>0020000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for character special devices.</p>
|
|
|
|
<p>0010000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">File type value
|
|
for named pipes or FIFOs.</p>
|
|
|
|
<p>0004000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">SUID bit.</p>
|
|
|
|
<p>0002000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">SGID bit.</p>
|
|
|
|
<p>0001000</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">Sticky bit. On
|
|
some systems, this modifies the behavior of executables
|
|
and/or directories.</p>
|
|
|
|
<p>0000777</p>
|
|
|
|
<p style="margin-left:28%; margin-top: 1em">The lower 9
|
|
bits specify read/write/execute permissions for world,
|
|
group, and user following standard POSIX conventions.</p>
|
|
|
|
<p style="margin-top: 1em"><i>uid</i>, <i>gid</i></p>
|
|
|
|
<p style="margin-left:17%;">The numeric user id and group
|
|
id of the owner.</p>
|
|
|
|
<p style="margin-top: 1em"><i>nlink</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">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.</p>
|
|
|
|
<p style="margin-top: 1em"><i>rdev</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">For block
|
|
special and character special entries, this field contains
|
|
the associated device number. For all other entry types, it
|
|
should be set to zero by writers and ignored by readers.</p>
|
|
|
|
<p style="margin-top: 1em"><i>mtime</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">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.</p>
|
|
|
|
<p style="margin-top: 1em"><i>namesize</i></p>
|
|
|
|
<p style="margin-left:17%;">The number of bytes in the
|
|
pathname that follows the header. This count includes the
|
|
trailing NUL byte.</p>
|
|
|
|
<p style="margin-top: 1em"><i>filesize</i></p>
|
|
|
|
<p style="margin-left:17%;">The size of the file. Note that
|
|
this archive format is limited to four gigabyte file sizes.
|
|
See <i>mtime</i> above for a description of the storage of
|
|
four-byte integers.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The pathname
|
|
immediately follows the fixed header. If the <b>namesize</b>
|
|
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.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">Hardlinked files
|
|
are not given special treatment; the full file contents are
|
|
included with each copy of the file.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>Portable
|
|
ASCII Format</b> <br>
|
|
Version 2 of the Single UNIX Specification
|
|
(’’SUSv2’’) standardized an ASCII
|
|
variant that is portable across all platforms. It is
|
|
commonly known as the ’’old
|
|
character’’ format or as the
|
|
’’odc’’ format. It stores the same
|
|
numeric fields as the old binary format, but represents them
|
|
as 6-character or 11-character octal values.</p>
|
|
|
|
<p style="margin-left:14%; margin-top: 1em">struct
|
|
cpio_odc_header { <br>
|
|
char c_magic[6]; <br>
|
|
char c_dev[6]; <br>
|
|
char c_ino[6]; <br>
|
|
char c_mode[6]; <br>
|
|
char c_uid[6]; <br>
|
|
char c_gid[6]; <br>
|
|
char c_nlink[6]; <br>
|
|
char c_rdev[6]; <br>
|
|
char c_mtime[11]; <br>
|
|
char c_namesize[6]; <br>
|
|
char c_filesize[11]; <br>
|
|
};</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The fields are
|
|
identical to those in the old binary format. The name and
|
|
file body follow the fixed header. Unlike the old binary
|
|
format, there is no additional padding after the pathname or
|
|
file contents. If the files being archived are themselves
|
|
entirely ASCII, then the resulting archive will be entirely
|
|
ASCII, except for the NUL byte that terminates the name
|
|
field.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>New ASCII
|
|
Format</b> <br>
|
|
The "new" ASCII format uses 8-byte hexadecimal
|
|
fields for all numbers and separates device numbers into
|
|
separate fields for major and minor numbers.</p>
|
|
|
|
<p style="margin-left:14%; margin-top: 1em">struct
|
|
cpio_newc_header { <br>
|
|
char c_magic[6]; <br>
|
|
char c_ino[8]; <br>
|
|
char c_mode[8]; <br>
|
|
char c_uid[8]; <br>
|
|
char c_gid[8]; <br>
|
|
char c_nlink[8]; <br>
|
|
char c_mtime[8]; <br>
|
|
char c_filesize[8]; <br>
|
|
char c_devmajor[8]; <br>
|
|
char c_devminor[8]; <br>
|
|
char c_rdevmajor[8]; <br>
|
|
char c_rdevminor[8]; <br>
|
|
char c_namesize[8]; <br>
|
|
char c_check[8]; <br>
|
|
};</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">Except as
|
|
specified below, the fields here match those specified for
|
|
the old binary format above.</p>
|
|
|
|
<p style="margin-top: 1em"><i>magic</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">The string
|
|
’’070701’’.</p>
|
|
|
|
<p style="margin-top: 1em"><i>check</i></p>
|
|
|
|
<p style="margin-left:17%; margin-top: 1em">This field is
|
|
always set to zero by writers and ignored by readers. See
|
|
the next section for more details.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The pathname is
|
|
followed by NUL bytes so that the total size of the fixed
|
|
header plus pathname is a multiple of four. Likewise, the
|
|
file data is padded to a multiple of four bytes. Note that
|
|
this format supports only 4 gigabyte files (unlike the older
|
|
ASCII format, which supports 8 gigabyte files).</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">In this format,
|
|
hardlinked files are handled by setting the filesize to zero
|
|
for each entry except the last one that appears in the
|
|
archive.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>New CRC
|
|
Format</b> <br>
|
|
The CRC format is identical to the new ASCII format
|
|
described in the previous section except that the magic
|
|
field is set to ’’070702’’ and the
|
|
<i>check</i> field is set to the sum of all bytes in the
|
|
file data. This sum is computed treating all bytes as
|
|
unsigned values and using unsigned arithmetic. Only the
|
|
least-significant 32 bits of the sum are stored.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>HP
|
|
variants</b> <br>
|
|
The <b>cpio</b> implementation distributed with HPUX used
|
|
XXXX but stored device numbers differently XXX.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em"><b>Other
|
|
Extensions and Variants</b> <br>
|
|
Sun Solaris uses additional file types to store extended
|
|
file data, including ACLs and extended attributes, as
|
|
special entries in cpio archives.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">XXX Others?
|
|
XXX</p>
|
|
|
|
<p style="margin-top: 1em"><b>SEE ALSO</b></p>
|
|
|
|
<p style="margin-left:6%;">cpio(1), tar(5)</p>
|
|
|
|
<p style="margin-top: 1em"><b>STANDARDS</b></p>
|
|
|
|
<p style="margin-left:6%;">The <b>cpio</b> utility is no
|
|
longer a part of POSIX or the Single Unix Standard. It last
|
|
appeared in Version 2 of the Single UNIX Specification
|
|
(’’SUSv2’’). It has been supplanted
|
|
in subsequent standards by pax(1). The portable ASCII format
|
|
is currently part of the specification for the pax(1)
|
|
utility.</p>
|
|
|
|
<p style="margin-top: 1em"><b>HISTORY</b></p>
|
|
|
|
<p style="margin-left:6%;">The original cpio utility was
|
|
written by Dick Haight while working in AT&T’s
|
|
Unix Support Group. It appeared in 1977 as part of PWB/UNIX
|
|
1.0, the ’’Programmer’s Work
|
|
Bench’’ derived from Version 6 AT&T
|
|
UNIX that was used internally at AT&T. Both the old
|
|
binary and old character formats were in use by 1980,
|
|
according to the System III source released by SCO under
|
|
their ’’Ancient Unix’’ license. The
|
|
character format was adopted as part of IEEE Std 1003.1-1988
|
|
(’’POSIX.1’’). XXX when did
|
|
"newc" appear? Who invented it? When did HP come
|
|
out with their variant? When did Sun introduce ACLs and
|
|
extended attributes? XXX</p>
|
|
|
|
<p style="margin-top: 1em"><b>BUGS</b></p>
|
|
|
|
<p style="margin-left:6%;">The
|
|
’’CRC’’ format is mis-named, as it
|
|
uses a simple checksum and not a cyclic redundancy
|
|
check.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The old binary
|
|
format is limited to 16 bits for user id, group id, device,
|
|
and inode numbers. It is limited to 4 gigabyte file
|
|
sizes.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The old ASCII
|
|
format is limited to 18 bits for the user id, group id,
|
|
device, and inode numbers. It is limited to 8 gigabyte file
|
|
sizes.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">The new ASCII
|
|
format is limited to 4 gigabyte file sizes.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">None of the cpio
|
|
formats store user or group names, which are essential when
|
|
moving files between systems with dissimilar user or group
|
|
numbering.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">Especially when
|
|
writing older cpio variants, it may be necessary to map
|
|
actual device/inode values to synthesized values that fit
|
|
the available fields. With very large filesystems, this may
|
|
be necessary even for the newer formats.</p>
|
|
|
|
<p style="margin-left:6%; margin-top: 1em">BSD
|
|
December 23, 2011 BSD</p>
|
|
<hr>
|
|
</body>
|
|
</html>
|