pax.html

unix 下的C开发手册,还用详细的例程。

<td align=left>Data
</table>
</pre>
<h6 align=center><xref table="Octet-oriented <I>cpio</i> Archive Entry"></xref>Table: Octet-oriented <i>cpio</i> Archive Entry</h6>
<h5><a name = "tag_001_014_1700_002">&nbsp;</a>The cpio Header</h5>
For each file in the archive, a header as defined previously will be written.
The information in the header fields will be written as streams of the ISO/IEC&nbsp;646:1991 standard
characters interpreted as octal numbers.
The octal numbers
will be extended to the necessary length by appending the ISO/IEC&nbsp;646:1991 standard
IRV zeros at the most-significant-digit end of the number;
the result is written to the most-significant-digit of the stream of octets
first.
The fields are interpreted as follows:
<dl compact>

<dt><b>c_magic</b><dd>
Identify the archive as being a transportable archive
by containing the identifying value
070707.


<dt><b>c_dev</b><dd>
<dt><b>c_ino</b><dd>Contains values that uniquely identify
the file within the archive (that is, no files will contain the same
pair of
<b>c_dev</b>
and
<b>c_ino</b>
values unless they are links to the same file).
The values will be determined in an
unspecified manner.


<dt><b>c_mode</b><dd>Contains the file type and access permissions as defined
in the following table:
<pre>
<table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>File Permissions Name</b>
<th align=center><b>Value</b>
<th align=center><b>Indicates</b>
<tr valign=top><td align=left>C_IRUSR
<td align=left>000400
<td align=left>Read by owner.
<tr valign=top><td align=left>C_IWUSR
<td align=left>000200
<td align=left>Write by owner.
<tr valign=top><td align=left>C_IXUSR
<td align=left>000100
<td align=left>Execute by owner.
<tr valign=top><td align=left>C_IRGRP
<td align=left>000040
<td align=left>Read by group.
<tr valign=top><td align=left>C_IWGRP
<td align=left>000020
<td align=left>Write by group.
<tr valign=top><td align=left>C_IXGRP
<td align=left>000010
<td align=left>Execute by group.
<tr valign=top><td align=left>C_IROTH
<td align=left>000004
<td align=left>Read by others.
<tr valign=top><td align=left>C_IWOTH
<td align=left>000002
<td align=left>Write by others.
<tr valign=top><td align=left>C_IXOTH
<td align=left>000001
<td align=left>Execute by others.
<tr valign=top><td align=left>C_ISUID
<td align=left>004000
<td align=left>Set <i>uid</i>.
<tr valign=top><td align=left>C_ISGID
<td align=left>002000
<td align=left>Set <i>gid</i>.
<tr valign=top><td align=left>C_ISVTX
<td align=left>001000
<td align=left>Reserved.
<tr valign=top><th align=left>File Type Name
<th align=left>Value
<th align=left>Indicates
<tr valign=top><td align=left>C_ISDIR
<td align=left>040000
<td align=left>Directory.
<tr valign=top><td align=left>C_ISFIFO
<td align=left>010000
<td align=left>FIFO.
<tr valign=top><td align=left>C_ISREG
<td align=left>0100000
<td align=left>Regular file.
<tr valign=top><td align=left>C_ISBLK
<td align=left>060000
<td align=left>Block special file.
<tr valign=top><td align=left>C_ISCHR
<td align=left>020000
<td align=left>Character special file.
<tr valign=top><td align=left>C_ISCTG
<td align=left>0110000
<td align=left>Reserved.
<tr valign=top><td align=left>C_ISLNK
<td align=left>0120000
<td align=left>Reserved.
<tr valign=top><td align=left>C_ISSOCK
<td align=left>0140000
<td align=left>Reserved.
</table>
</pre>
<h6 align=center><xref table="Values for <I>cpio</i> <b>c_mode</b> Field"></xref>Table: Values for <i>cpio</i> <b>c_mode</b> Field</h6>

Directories, FIFOs and regular files
are supported on a
system conforming to this specification;
additional values defined previously are
reserved for compatibility with existing systems.
Additional file types may be supported;
however, such files should not be
written to
archives intended to be transported to other systems.

<dt><b>c_uid</b><dd>Contains the user ID of the owner.

<dt><b>c_gid</b><dd>Contains the group ID of the group.

<dt><b>c_nlink</b><dd>Contains the number of links referencing
the file at the time the archive was created.

<dt><b>c_rdev</b><dd>Contains implementation-dependent information for character
or block special files.

<dt><b>c_mtime</b><dd>
Contains the latest time of modification of the file
at the time the archive was created.

<dt><b>c_namesize</b><dd>
Contains the length of the pathname, including the
terminating NUL character.

<dt><b>c_filesize</b><dd>
Contains the length of the file in octets.
This will be the length of the data section following the header structure.

</dl>
<h5><a name = "tag_001_014_1700_003">&nbsp;</a>The cpio Filename</h5>
The
<b>c_name</b>
field contains the pathname of the file.
The length of this field in octets is the value of
<i>c_namesize .</i>
If a filename
is found on the medium that would create an invalid pathname,
it is implementation-dependent if the data from the file is
stored on the file hierarchy and under what name it is stored.
<p>
All characters are represented in the ISO/IEC&nbsp;646:1991 standard IRV.
For maximum portability between implementations,
names should be selected from characters represented by the
portable filename character set
as octets with the most significant bit zero.
If an implementation supports the use of characters
outside the portable filename character set in names for
files, users and groups, one or more implementation-dependent
encodings of these characters will be provided for
interchange purposes.
However, the
<i>pax</i>
utility will never create
filenames on the local system that cannot be accessed via the
procedures described previously in this specification.
If a filename is found on the medium that would create an
invalid filename, it is implementation-dependent
if the data from the file is stored on the local file system
and under what name it is stored.
The
<i>pax</i>
utility may choose to ignore these files
as long as it produces an error indicating that the file is being ignored.
<h5><a name = "tag_001_014_1700_004">&nbsp;</a>The cpio File Data</h5>
Following
<i>c_name ,</i>
there are
<b>c_filesize</b>
octets of data.
Interpretation of such data occurs in a manner dependent on the file.
If
<b>c_filesize</b>
is zero, no data will be contained in
<i>c_filedata .</i>
<p>
When restoring from an archive:
<ul>
<p>
<li>
If the user does not have the appropriate privilege to create a
file of the specified type,
<i>pax</i>
will ignore the entry and write an error message to standard error.
<p>
<li>
Only regular files have data to be restored.
Presuming a
regular file meets any selection criteria that might be
imposed on the format-reading utility by the user, such data
will be restored.
<p>
<li>
If a user does not have appropriate privilege to set a
particular mode flag, the flag will be ignored.
Some of the
mode flags in the archive format are not mentioned elsewhere in
this specification.
If the implementation does not support those
flags, they may be ignored.
<p>
</ul>
<h5><a name = "tag_001_014_1700_005">&nbsp;</a>The cpio Special Entries</h5>
FIFO
special files, directories and the trailer are recorded with
<b>c_filesize</b>
equal to zero.
For other special files,
<b>c_filesize</b>
is unspecified by this specification.
The header for the next file entry
in the archive will be written directly
after the last octet of the file entry preceding it.
A header denoting the filename
TRAILER!!!
indicates
the end of the archive; the contents of octets in the last block of the
archive following such a header are undefined.
<h5><a name = "tag_001_014_1700_006">&nbsp;</a>Extended tar Format</h5>
An extended
<i><a href="tar.html">tar</a></i>
archive file contains a series of blocks.
Each block will be a fixed-size block of 512 octets (see below).
Each file archived is represented by a header block
that describes the file, followed by zero or more
blocks that give the contents of the file.
At the end of the archive file there will be two blocks filled with binary
zeros, interpreted as an end-of-archive indicator.
<p>
The blocks may be grouped for physical I/O operations.
Each group of
<i>n</i>
blocks (where
<i>n</i>
is set by the
<i>pax</i>
<b>-b</b>
option)
may be written with a single write operation.
On magnetic tape, the result of this write will be a single tape record.
The last group of blocks always will be at the full size, so
blocks after the two zero blocks may contain undefined data.
<p>
The header block will be structured as shown in the following table.
All lengths and offsets are in decimal.
<pre>
<table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Field Name</b>
<th align=center><b>Octet Offset</b>
<th align=center><b>Length (in Octets)</b>
<tr valign=top><td align=left><i>name</i>
<td align=left>0
<td align=left>100
<tr valign=top><td align=left><i>mode</i>
<td align=left>100
<td align=left>8
<tr valign=top><td align=left><i>uid</i>
<td align=left>108
<td align=left>8
<tr valign=top><td align=left><i>gid</i>
<td align=left>116
<td align=left>8
<tr valign=top><td align=left><i>size</i>
<td align=left>124
<td align=left>12
<tr valign=top><td align=left><i>mtime</i>
<td align=left>136
<td align=left>12
<tr valign=top><td align=left><i>chksum</i>
<td align=left>148
<td align=left>8
<tr valign=top><td align=left><i>typeflag</i>
<td align=left>156
<td align=left>1
<tr valign=top><td align=left><i>linkname</i>
<td align=left>157
<td align=left>100
<tr valign=top><td align=left><i>magic</i>
<td align=left>257
<td align=left>6
<tr valign=top><td align=left><i>version</i>
<td align=left>263
<td align=left>2
<tr valign=top><td align=left><i>uname</i>
<td align=left>265
<td align=left>32
<tr valign=top><td align=left><i>gname</i>
<td align=left>297
<td align=left>32
<tr valign=top><td align=left><i>devmajor</i>
<td align=left>329
<td align=left>8
<tr valign=top><td align=left><i>devminor</i>
<td align=left>337
<td align=left>8
<tr valign=top><td align=left><i>prefix</i>
<td align=left>345
<td align=left>155
</table>
</pre>
<h6 align=center><xref table="Extended <I>tar</i> Header Block"></xref>Table: Extended <i>tar</i> Header Block</h6>
<p>
All characters in the header block
are represented in the coded character set of the ISO/IEC&nbsp;646:1991 standard.
For maximum portability between implementations,
names should be selected
from characters represented by the
portable filename character set
as octets with the most significant bit zero.
If an implementation supports the use of characters
outside the portable filename character set in names for
files, users and groups, one or more implementation-dependent
encodings of these characters will be provided for
interchange purposes.
However, the
<i>pax</i>
utility will never create
filenames on the local system that cannot be accessed via the
procedures described previously in this specification.
If a filename is found on the medium that would create an
invalid filename, it is implementation-dependent
if the data from the file is stored on the file hierarchy
and under what name it is stored.
The
<i>pax</i>
utility may choose to ignore these files
as long as it produces an error indicating that the file is being ignored.
<p>
Each field within the
header block is contiguous;
that is, there is no padding used.
Each character on the archive medium is stored contiguously.
<p>
The fields
<b>magic</b>,
<b>uname</b>
and
<b>gname</b>
are character strings each terminated by a NUL character.
The fields
<b>name</b>,
<b>linkname</b>
and
<b>prefix</b>
are NUL-terminated character strings except when all characters
in the array contain non-NUL characters including the last character.
The
<b>version</b>
field is two octets containing the characters <b>00</b> (zero-zero).
The
<i>typeflag</i>
contains a single character.
All other fields
are leading zero-filled octal numbers
using digits from the ISO/IEC&nbsp;646:1991 standard IRV.
Each numeric field is terminated by one or more space
or NUL characters.
<p>
The
<b>name</b>
and the
<b>prefix</b>
fields produce the pathname of the file.
The hierarchical relationship of the file can be retained by specifying the
pathname as a path prefix, and a
slash character and filename as the suffix.
A new pathname is formed, if
<i>prefix</i>
is not an empty string (its first
character is not NUL), by concatenating
<i>prefix</i>
(up to the first NUL
character), a slash character and
<i>name ;</i>
otherwise,
<i>name</i>
is used alone.
In either case,
<i>name</i>
is terminated at the first NUL character.
If
<i>prefix</i>
begins with a NUL character, it will be ignored.
In this manner, pathnames of at most
256 characters can be supported.
If a pathname does not fit in the space provided,
<i>pax</i>
will notify the user of the error,
and will not store any part of the
file  header or data  on the medium.
<p>
The
<b>linkname</b>
field, described below, does not use the
<i>prefix</i>
to produce a pathname.
As such, a
<i>linkname</i>
is limited to
100 characters.
If the name does not fit in the space provided,
<i>pax</i>
will notify the user of
the error, and will not attempt to store
the link on the medium.
<p>
The
<b>mode</b>
field provides 12 bits encoded in the ISO/IEC&nbsp;646:1991 standard
octal digit representation.
The encoded bits represent the following values:
<dl compact>

<dt><b>04000</b><dd>Set UID on execution.

<dt><b>02000</b><dd>Set GID on execution.

<dt><b>01000</b><dd>Reserved.

<dt><b>00400</b><dd>Read by owner.