mirror of
https://github.com/cmclark00/retro-imager.git
synced 2025-05-19 16:35:20 +01:00
Qt/QML edition
This commit is contained in:
Floris Bos
commit
d7b361ba44
2168 changed files with 721948 additions and 0 deletions
415
dependencies/libarchive-3.4.2/doc/html/cpio.5.html
vendored
Normal file
415
dependencies/libarchive-3.4.2/doc/html/cpio.5.html
vendored
Normal file
|
|
@ -0,0 +1,415 @@
|
|||
<!-- 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>
|
||||
Loading…
Add table
Add a link
Reference in a new issue