обмен переносными архивами (portable archive interchange)
Расширенное описание (Extended description)
pax Interchange Format
A pax archive tape or file produced in the -xpax format shall
contain a series of blocks. The physical layout of the archive
shall be identical to the ustar format described in ustar
Interchange Format. Each file archived shall be represented by
the following sequence:
* An optional header block with extended header records. This
header block is of the form described in pax Header Block,
with a typeflag value of x or g. The extended header
records, described in pax Extended Header, shall be included
as the data for this header block.
* A header block that describes the file. Any fields in the
preceding optional extended header shall override the
associated fields in this header block for this file.
* Zero or more blocks that contain the contents of the file.
At the end of the archive file there shall be two 512-byte blocks
filled with binary zeros, interpreted as an end-of-archive
indicator.
A schematic of an example archive with global extended header
records and two actual files is shown in Figure 4-1, pax Format
Archive Example. In the example, the second file in the archive
has no extended header preceding it, presumably because it has no
need for extended attributes.
Figure 4-1: pax Format Archive Example
pax Header Block
The pax header block shall be identical to the ustar header block
described in ustar Interchange Format, except that two additional
typeflag values are defined:
x Represents extended header records for the following file
in the archive (which shall have its own ustar header
block). The format of these extended header records shall
be as described in pax Extended Header.
g Represents global extended header records for the following
files in the archive. The format of these extended header
records shall be as described in pax Extended Header. Each
value shall affect all subsequent files that do not
override that value in their own extended header record and
until another global extended header record is reached that
provides another value for the same field. The typeflag g
global headers should not be used with interchange media
that could suffer partial data loss in transporting the
archive.
For both of these types, the size field shall be the size of the
extended header records in octets. The other fields in the header
block are not meaningful to this version of the pax utility.
However, if this archive is read by a pax utility conforming to
the ISO POSIX‐2:1993 standard, the header block fields are used
to create a regular file that contains the extended header
records as data. Therefore, header block field values should be
selected to provide reasonable file access to this regular file.
A further difference from the ustar header block is that data
blocks for files of typeflag 1 (the digit one) (hard link) may be
included, which means that the size field may be greater than
zero. Archives created by pax -o linkdata shall include these
data blocks with the hard links.
pax Extended Header
A pax extended header contains values that are inappropriate for
the ustar header block because of limitations in that format:
fields requiring a character encoding other than that described
in the ISO/IEC 646:1991 standard, fields representing file
attributes not described in the ustar header, and fields whose
format or length do not fit the requirements of the ustar header.
The values in an extended header add attributes to the following
file (or files; see the description of the typeflag g header
block) or override values in the following header block(s), as
indicated in the following list of keywords.
An extended header shall consist of one or more records, each
constructed as follows:
"%d %s=%s\n", <length>, <keyword>, <value>
The extended header records shall be encoded according to the
ISO/IEC 10646‐1:2000 standard UTF‐8 encoding. The <length> field,
<blank>, <equals-sign>, and <newline> shown shall be limited to
the portable character set, as encoded in UTF‐8. The <keyword>
fields can be any UTF‐8 characters. The <length> field shall be
the decimal length of the extended header record in octets,
including the trailing <newline>. If there is a hdrcharset
extended header in effect for a file, the value field for any
gname, linkpath, path, and uname extended header records shall be
encoded using the character set specified by the hdrcharset
extended header record; otherwise, the value field shall be
encoded using UTF‐8. The value field for all other keywords
specified by POSIX.1‐2008 shall be encoded using UTF‐8.
The <keyword> field shall be one of the entries from the
following list or a keyword provided as an implementation
extension. Keywords consisting entirely of lowercase letters,
digits, and periods are reserved for future standardization. A
keyword shall not include an <equals-sign>. (In the following
list, the notations ``file(s)'' or ``block(s)'' is used to
acknowledge that a keyword affects the following single file
after a typeflag x extended header, but possibly multiple files
after typeflag g. Any requirements in the list for pax to
include a record when in write or copy mode shall apply only when
such a record has not already been provided through the use of
the -o option. When used in copy mode, pax shall behave as if an
archive had been created with applicable extended header records
and then extracted.)
atime The file access time for the following file(s),
equivalent to the value of the st_atime member of the
stat structure for a file, as described by the stat()
function. The access time shall be restored if the
process has appropriate privileges required to do so.
The format of the <value> shall be as described in pax
Extended Header File Times.
charset The name of the character set used to encode the data
in the following file(s). The entries in the following
table are defined to refer to known standards;
additional names may be agreed on between the
originator and recipient.
┌────────────────────────┬───────────────────────────────┐
│ <value> │ Formal Standard │
├────────────────────────┼───────────────────────────────┤
│ISO-IR 646 1990 │ ISO/IEC 646:1990 │
│ISO-IR 8859 1 1998 │ ISO/IEC 8859‐1:1998 │
│ISO-IR 8859 2 1999 │ ISO/IEC 8859‐2:1999 │
│ISO-IR 8859 3 1999 │ ISO/IEC 8859‐3:1999 │
│ISO-IR 8859 4 1998 │ ISO/IEC 8859‐4:1998 │
│ISO-IR 8859 5 1999 │ ISO/IEC 8859‐5:1999 │
│ISO-IR 8859 6 1999 │ ISO/IEC 8859‐6:1999 │
│ISO-IR 8859 7 1987 │ ISO/IEC 8859‐7:1987 │
│ISO-IR 8859 8 1999 │ ISO/IEC 8859‐8:1999 │
│ISO-IR 8859 9 1999 │ ISO/IEC 8859‐9:1999 │
│ISO-IR 8859 10 1998 │ ISO/IEC 8859‐10:1998 │
│ISO-IR 8859 13 1998 │ ISO/IEC 8859‐13:1998 │
│ISO-IR 8859 14 1998 │ ISO/IEC 8859‐14:1998 │
│ISO-IR 8859 15 1999 │ ISO/IEC 8859‐15:1999 │
│ISO-IR 10646 2000 │ ISO/IEC 10646:2000 │
│ISO-IR 10646 2000 UTF-8 │ ISO/IEC 10646, UTF-8 encoding │
│BINARY │ None. │
└────────────────────────┴───────────────────────────────┘
The encoding is included in an extended header for
information only; when pax is used as described in
POSIX.1‐2008, it shall not translate the file data into
any other encoding. The BINARY entry indicates
unencoded binary data.
When used in write or copy mode, it is implementation-
defined whether pax includes a charset extended header
record for a file.
comment A series of characters used as a comment. All
characters in the <value> field shall be ignored by
pax.
gid The group ID of the group that owns the file, expressed
as a decimal number using digits from the
ISO/IEC 646:1991 standard. This record shall override
the gid field in the following header block(s). When
used in write or copy mode, pax shall include a gid
extended header record for each file whose group ID is
greater than 2097151 (octal 7777777).
gname The group of the file(s), formatted as a group name in
the group database. This record shall override the gid
and gname fields in the following header block(s), and
any gid extended header record. When used in read,
copy, or list mode, pax shall translate the name from
the encoding in the header record to the character set
appropriate for the group database on the receiving
system. If any of the characters cannot be translated,
and if neither the -oinvalid=UTF‐8 option nor the
-oinvalid=binary option is specified, the results are
implementation-defined. When used in write or copy
mode, pax shall include a gname extended header record
for each file whose group name cannot be represented
entirely with the letters and digits of the portable
character set.
hdrcharset
The name of the character set used to encode the value
field of the gname, linkpath, path, and uname pax
extended header records. The entries in the following
table are defined to refer to known standards;
additional names may be agreed between the originator
and the recipient.
┌────────────────────────┬───────────────────────────────┐
│ <value> │ Formal Standard │
├────────────────────────┼───────────────────────────────┤
│ISO-IR 10646 2000 UTF-8 │ ISO/IEC 10646, UTF-8 encoding │
│BINARY │ None. │
└────────────────────────┴───────────────────────────────┘
If no hdrcharset extended header record is specified,
the default character set used to encode all values in
extended header records shall be the
ISO/IEC 10646‐1:2000 standard UTF‐8 encoding.
The BINARY entry indicates that all values recorded in
extended headers for affected files are unencoded
binary data from the underlying system.
linkpath The pathname of a link being created to another file,
of any type, previously archived. This record shall
override the linkname field in the following ustar
header block(s). The following ustar header block shall
determine the type of link created. If typeflag of the
following header block is 1, it shall be a hard link.
If typeflag is 2, it shall be a symbolic link and the
linkpath value shall be the contents of the symbolic
link. The pax utility shall translate the name of the
link (contents of the symbolic link) from the encoding
in the header to the character set appropriate for the
local file system. When used in write or copy mode, pax
shall include a linkpath extended header record for
each link whose pathname cannot be represented entirely
with the members of the portable character set other
than NUL.
mtime The file modification time of the following file(s),
equivalent to the value of the st_mtime member of the
stat structure for a file, as described in the stat()
function. This record shall override the mtime field in
the following header block(s). The modification time
shall be restored if the process has appropriate
privileges required to do so. The format of the <value>
shall be as described in pax Extended Header File
Times.
path The pathname of the following file(s). This record
shall override the name and prefix fields in the
following header block(s). The pax utility shall
translate the pathname of the file from the encoding in
the header to the character set appropriate for the
local file system.
When used in write or copy mode, pax shall include a
path extended header record for each file whose
pathname cannot be represented entirely with the
members of the portable character set other than NUL.
realtime.any
The keywords prefixed by ``realtime.'' are reserved for
future standardization.
security.any
The keywords prefixed by ``security.'' are reserved for
future standardization.
size The size of the file in octets, expressed as a decimal
number using digits from the ISO/IEC 646:1991 standard.
This record shall override the size field in the
following header block(s). When used in write or copy
mode, pax shall include a size extended header record
for each file with a size value greater than 8589934591
(octal 77777777777).
uid The user ID of the file owner, expressed as a decimal
number using digits from the ISO/IEC 646:1991 standard.
This record shall override the uid field in the
following header block(s). When used in write or copy
mode, pax shall include a uid extended header record
for each file whose owner ID is greater than 2097151
(octal 7777777).
uname The owner of the following file(s), formatted as a user
name in the user database. This record shall override
the uid and uname fields in the following header
block(s), and any uid extended header record. When used
in read, copy, or list mode, pax shall translate the
name from the encoding in the header record to the
character set appropriate for the user database on the
receiving system. If any of the characters cannot be
translated, and if neither the -oinvalid=UTF‐8 option
nor the -oinvalid=binary option is specified, the
results are implementation-defined. When used in write
or copy mode, pax shall include a uname extended header
record for each file whose user name cannot be
represented entirely with the letters and digits of the
portable character set.
If the <value> field is zero length, it shall delete any header
block field, previously entered extended header value, or global
extended header value of the same name.
If a keyword in an extended header record (or in a -o option-
argument) overrides or deletes a corresponding field in the ustar
header block, pax shall ignore the contents of that header block
field.
Unlike the ustar header block fields, NULs shall not delimit
<value>s; all characters within the <value> field shall be
considered data for the field. None of the length limitations of
the ustar header block fields in Table 4-14, ustar Header Block
shall apply to the extended header records.
pax Extended Header Keyword Precedence
This section describes the precedence in which the various header
records and fields and command line options are selected to apply
to a file in the archive. When pax is used in read or list modes,
it shall determine a file attribute in the following sequence:
1. If -odelete=keyword-prefix is used, the affected attributes
shall be determined from step 7., if applicable, or ignored
otherwise.
2. If -okeyword:= is used, the affected attributes shall be
ignored.
3. If -okeyword:=value is used, the affected attribute shall be
assigned the value.
4. If there is a typeflag x extended header record, the affected
attribute shall be assigned the <value>. When extended header
records conflict, the last one given in the header shall take
precedence.
5. If -okeyword=value is used, the affected attribute shall be
assigned the value.
6. If there is a typeflag g global extended header record, the
affected attribute shall be assigned the <value>. When global
extended header records conflict, the last one given in the
global header shall take precedence.
7. Otherwise, the attribute shall be determined from the ustar
header block.
pax Extended Header File Times
The pax utility shall write an mtime record for each file in
write or copy modes if the file's modification time cannot be
represented exactly in the ustar header logical record described
in ustar Interchange Format. This can occur if the time is out
of ustar range, or if the file system of the underlying
implementation supports non-integer time granularities and the
time is not an integer. All of these time records shall be
formatted as a decimal representation of the time in seconds
since the Epoch. If a <period> ('.') decimal point character is
present, the digits to the right of the point shall represent the
units of a subsecond timing granularity, where the first digit is
tenths of a second and each subsequent digit is a tenth of the
previous digit. In read or copy mode, the pax utility shall
truncate the time of a file to the greatest value that is not
greater than the input header file time. In write or copy mode,
the pax utility shall output a time exactly if it can be
represented exactly as a decimal number, and otherwise shall
generate only enough digits so that the same time shall be
recovered if the file is extracted on a system whose underlying
implementation supports the same time granularity.
ustar Interchange Format
A ustar archive tape or file shall contain a series of logical
records. Each logical record shall be a fixed-size logical record
of 512 octets (see below). Although this format may be thought of
as being stored on 9-track industry-standard 12.7 mm (0.5 in)
magnetic tape, other types of transportable media are not
excluded. Each file archived shall be represented by a header
logical record that describes the file, followed by zero or more
logical records that give the contents of the file. At the end of
the archive file there shall be two 512-octet logical records
filled with binary zeros, interpreted as an end-of-archive
indicator.
The logical records may be grouped for physical I/O operations,
as described under the -bblocksize and -x ustar options. Each
group of logical records may be written with a single operation
equivalent to the write() function. On magnetic tape, the result
of this write shall be a single tape physical block. The last
physical block shall always be the full size, so logical records
after the two zero logical records may contain undefined data.
The header logical record shall be structured as shown in the
following table. All lengths and offsets are in decimal.
Table 4-14: ustar Header Block
┌───────────┬──────────────┬────────────────────┐
│Field Name │ Octet Offset │ Length (in Octets) │
├───────────┼──────────────┼────────────────────┤
│name │ 0 │ 100 │
│mode │ 100 │ 8 │
│uid │ 108 │ 8 │
│gid │ 116 │ 8 │
│size │ 124 │ 12 │
│mtime │ 136 │ 12 │
│chksum │ 148 │ 8 │
│typeflag │ 156 │ 1 │
│linkname │ 157 │ 100 │
│magic │ 257 │ 6 │
│version │ 263 │ 2 │
│uname │ 265 │ 32 │
│gname │ 297 │ 32 │
│devmajor │ 329 │ 8 │
│devminor │ 337 │ 8 │
│prefix │ 345 │ 155 │
└───────────┴──────────────┴────────────────────┘
All characters in the header logical record shall be represented
in the coded character set of the ISO/IEC 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 of <slash>
and the portable filename character set in names for files,
users, and groups, one or more implementation-defined encodings
of these characters shall be provided for interchange purposes.
However, the pax utility shall never create filenames on the
local system that cannot be accessed via the procedures described
in POSIX.1‐2008. If a filename is found on the medium that would
create an invalid filename, it is implementation-defined whether
the data from the file is stored on the file hierarchy and under
what name it is stored. The pax utility may choose to ignore
these files as long as it produces an error indicating that the
file is being ignored.
Each field within the header logical record is contiguous; that
is, there is no padding used. Each character on the archive
medium shall be stored contiguously.
The fields magic, uname, and gname are character strings each
terminated by a NUL character. The fields name, linkname, and
prefix are NUL-terminated character strings except when all
characters in the array contain non-NUL characters including the
last character. The version field is two octets containing the
characters "00" (zero-zero). The typeflag contains a single
character. All other fields are leading zero-filled octal numbers
using digits from the ISO/IEC 646:1991 standard IRV. Each numeric
field is terminated by one or more <space> or NUL characters.
The name and the prefix fields shall produce the pathname of the
file. A new pathname shall be formed, if prefix is not an empty
string (its first character is not NUL), by concatenating prefix
(up to the first NUL character), a <slash> character, and name;
otherwise, name is used alone. In either case, name is terminated
at the first NUL character. If prefix begins with a NUL
character, it shall be ignored. In this manner, pathnames of at
most 256 characters can be supported. If a pathname does not fit
in the space provided, pax shall notify the user of the error,
and shall not store any part of the file—header or data—on the
medium.
The linkname field, described below, shall not use the prefix to
produce a pathname. As such, a linkname is limited to 100
characters. If the name does not fit in the space provided, pax
shall notify the user of the error, and shall not attempt to
store the link on the medium.
The mode field provides 12 bits encoded in the ISO/IEC 646:1991
standard octal digit representation. The encoded bits shall
represent the following values:
Table: ustar mode Field
┌──────────┬──────────────────┬─────────────────────────────────────────────────┐
│Bit Value │ POSIX.1‐2008 Bit │ Description │
├──────────┼──────────────────┼─────────────────────────────────────────────────┤
│ 04000 │ S_ISUID │ Set UID on execution. │
│ 02000 │ S_ISGID │ Set GID on execution. │
│ 01000 │ <reserved> │ Reserved for future standardization. │
│ 00400 │ S_IRUSR │ Read permission for file owner class. │
│ 00200 │ S_IWUSR │ Write permission for file owner class. │
│ 00100 │ S_IXUSR │ Execute/search permission for file owner class. │
│ 00040 │ S_IRGRP │ Read permission for file group class. │
│ 00020 │ S_IWGRP │ Write permission for file group class. │
│ 00010 │ S_IXGRP │ Execute/search permission for file group class. │
│ 00004 │ S_IROTH │ Read permission for file other class. │
│ 00002 │ S_IWOTH │ Write permission for file other class. │
│ 00001 │ S_IXOTH │ Execute/search permission for file other class. │
└──────────┴──────────────────┴─────────────────────────────────────────────────┘
When appropriate privileges are required to set one of these mode
bits, and the user restoring the files from the archive does not
have appropriate privileges, the mode bits for which the user
does not have appropriate privileges shall be ignored. Some of
the mode bits in the archive format are not mentioned elsewhere
in this volume of POSIX.1‐2017. If the implementation does not
support those bits, they may be ignored.
The uid and gid fields are the user and group ID of the owner and
group of the file, respectively.
The size field is the size of the file in octets. If the typeflag
field is set to specify a file to be of type 1 (a link) or 2 (a
symbolic link), the size field shall be specified as zero. If the
typeflag field is set to specify a file of type 5 (directory),
the size field shall be interpreted as described under the
definition of that record type. No data logical records are
stored for types 1, 2, or 5. If the typeflag field is set to 3
(character special file), 4 (block special file), or 6 (FIFO),
the meaning of the size field is unspecified by this volume of
POSIX.1‐2017, and no data logical records shall be stored on the
medium. Additionally, for type 6, the size field shall be ignored
when reading. If the typeflag field is set to any other value,
the number of logical records written following the header shall
be (size+511)/512, ignoring any fraction in the result of the
division.
The mtime field shall be the modification time of the file at the
time it was archived. It is the ISO/IEC 646:1991 standard
representation of the octal value of the modification time
obtained from the stat() function.
The chksum field shall be the ISO/IEC 646:1991 standard IRV
representation of the octal value of the simple sum of all octets
in the header logical record. Each octet in the header shall be
treated as an unsigned value. These values shall be added to an
unsigned integer, initialized to zero, the precision of which is
not less than 17 bits. When calculating the checksum, the chksum
field is treated as if it were all <space> characters.
The typeflag field specifies the type of file archived. If a
particular implementation does not recognize the type, or the
user does not have appropriate privileges to create that type,
the file shall be extracted as if it were a regular file if the
file type is defined to have a meaning for the size field that
could cause data logical records to be written on the medium (see
the previous description for size). If conversion to a regular
file occurs, the pax utility shall produce an error indicating
that the conversion took place. All of the typeflag fields shall
be coded in the ISO/IEC 646:1991 standard IRV:
0 Represents a regular file. For backwards-compatibility, a
typeflag value of binary zero ('\0') should be recognized
as meaning a regular file when extracting files from the
archive. Archives written with this version of the
archive file format create regular files with a typeflag
value of the ISO/IEC 646:1991 standard IRV '0'.
1 Represents a file linked to another file, of any type,
previously archived. Such files are identified by having
the same device and file serial numbers, and pathnames
that refer to different directory entries. All such files
shall be archived as linked files. The linked-to name is
specified in the linkname field with a NUL-character
terminator if it is less than 100 octets in length.
2 Represents a symbolic link. The contents of the symbolic
link shall be stored in the linkname field.
3,4 Represent character special files and block special files
respectively. In this case the devmajor and devminor
fields shall contain information defining the device, the
format of which is unspecified by this volume of
POSIX.1‐2017. Implementations may map the device
specifications to their own local specification or may
ignore the entry.
5 Specifies a directory or subdirectory. On systems where
disk allocation is performed on a directory basis, the
size field shall contain the maximum number of octets
(which may be rounded to the nearest disk block
allocation unit) that the directory may hold. A size
field of zero indicates no such limiting. Systems that do
not support limiting in this manner should ignore the
size field.
6 Specifies a FIFO special file. Note that the archiving of
a FIFO file archives the existence of this file and not
its contents.
7 Reserved to represent a file to which an implementation
has associated some high-performance attribute.
Implementations without such extensions should treat this
file as a regular file (type 0).
A‐Z The letters 'A' to 'Z', inclusive, are reserved for
custom implementations. All other values are reserved for
future versions of this standard.
It is unspecified whether files with pathnames that refer to the
same directory entry are archived as linked files or as separate
files. If they are archived as linked files, this means that
attempting to extract both pathnames from the resulting archive
will always cause an error (unless the -u option is used) because
the link cannot be created.
It is unspecified whether files with the same device and file
serial numbers being appended to an archive are treated as linked
files to members that were in the archive before the append.
Attempts to archive a socket shall produce a diagnostic message
when ustar interchange format is used, but may be allowed when
pax interchange format is used. Handling of other file types is
implementation-defined.
The magic field is the specification that this archive was output
in this archive format. If this field contains ustar (the five
characters from the ISO/IEC 646:1991 standard IRV shown followed
by NUL), the uname and gname fields shall contain the
ISO/IEC 646:1991 standard IRV representation of the owner and
group of the file, respectively (truncated to fit, if necessary).
When the file is restored by a privileged, protection-preserving
version of the utility, the user and group databases shall be
scanned for these names. If found, the user and group IDs
contained within these files shall be used rather than the values
contained within the uid and gid fields.
cpio Interchange Format
The octet-oriented cpio archive format shall be a series of
entries, each comprising a header that describes the file, the
name of the file, and then the contents of the file.
An archive may be recorded as a series of fixed-size blocks of
octets. This blocking shall be used only to make physical I/O
more efficient. The last group of blocks shall always be at the
full size.
For the octet-oriented cpio archive format, the individual entry
information shall be in the order indicated and described by the
following table; see also the <cpio.h> header.
Table 4-16: Octet-Oriented cpio Archive Entry
┌─────────────────────┬────────────────────┬─────────────────┐
│ Header Field Name │ Length (in Octets) │ Interpreted as │
├─────────────────────┼────────────────────┼─────────────────┤
│c_magic │ 6 │ Octal number │
│c_dev │ 6 │ Octal number │
│c_ino │ 6 │ Octal number │
│c_mode │ 6 │ Octal number │
│c_uid │ 6 │ Octal number │
│c_gid │ 6 │ Octal number │
│c_nlink │ 6 │ Octal number │
│c_rdev │ 6 │ Octal number │
│c_mtime │ 11 │ Octal number │
│c_namesize │ 6 │ Octal number │
│c_filesize │ 11 │ Octal number │
├─────────────────────┼────────────────────┼─────────────────┤
│Filename Field Name │ Length │ Interpreted as │
├─────────────────────┴────────────────────┴─────────────────┤
│c_name c_namesize Pathname string │
├─────────────────────┬────────────────────┬─────────────────┤
│File Data Field Name │ Length │ Interpreted as │
├─────────────────────┴────────────────────┴─────────────────┤
│c_filedata c_filesize Data │
└────────────────────────────────────────────────────────────┘
cpio Header
For each file in the archive, a header as defined previously
shall be written. The information in the header fields is written
as streams of the ISO/IEC 646:1991 standard characters
interpreted as octal numbers. The octal numbers shall be extended
to the necessary length by appending the ISO/IEC 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 shall be interpreted as
follows:
c_magic Identify the archive as being a transportable archive
by containing the identifying value "070707".
c_dev, c_ino
Contains values that uniquely identify the file within
the archive (that is, no files contain the same pair of
c_dev and c_ino values unless they are links to the
same file). The values shall be determined in an
unspecified manner.
c_mode Contains the file type and access permissions as
defined in the following table.
Table 4-17: Values for cpio c_mode Field
─┬──────────────────────┬─────────┬────────────────────────│
│File Permissions Name │ Value │ Indicates │
─┼──────────────────────┼─────────┼────────────────────────│
│C_IRUSR │ 000400 │Read by owner │
│C_IWUSR │ 000200 │Write by owner │
│C_IXUSR │ 000100 │Execute by owner │
│C_IRGRP │ 000040 │Read by group │
│C_IWGRP │ 000020 │Write by group │
│C_IXGRP │ 000010 │Execute by group │
│C_IROTH │ 000004 │Read by others │
│C_IWOTH │ 000002 │Write by others │
│C_IXOTH │ 000001 │Execute by others │
│C_ISUID │ 004000 │Set uid │
│C_ISGID │ 002000 │Set gid │
│C_ISVTX │ 001000 │Reserved │
─┼──────────────────────┼─────────┼────────────────────────│
│ File Type Name │ Value │ Indicates │
─┼──────────────────────┼─────────┼────────────────────────│
│C_ISDIR │ 040000 │Directory │
│C_ISFIFO │ 010000 │FIFO │
│C_ISREG │0100000 │Regular file │
│C_ISLNK │0120000 │Symbolic link │
│ │ │ │
│C_ISBLK │ 060000 │ Block special file │
│C_ISCHR │ 020000 │ Character special file │
│C_ISSOCK │ 0140000 │ Socket │
│ │ │ │
│C_ISCTG │ 0110000 │ Reserved │
└──────────────────────┴─────────┴────────────────────────┘
Directories, FIFOs, symbolic links, and regular files
shall be supported on a system conforming to this
volume of POSIX.1‐2017; 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.
c_uid Contains the user ID of the owner.
c_gid Contains the group ID of the group.
c_nlink Contains a number greater than or equal to the number
of links in the archive referencing the file. If the -a
option is used to append to a cpio archive, then the
pax utility need not account for the files in the
existing part of the archive when calculating the
c_nlink values for the appended part of the archive,
and need not alter the c_nlink values in the existing
part of the archive if additional files with the same
c_dev and c_ino values are appended to the archive.
c_rdev Contains implementation-defined information for
character or block special files.
c_mtime Contains the latest time of modification of the file at
the time the archive was created.
c_namesize
Contains the length of the pathname, including the
terminating NUL character.
c_filesize
Contains the length in octets of the data section
following the header structure.
cpio Filename
The c_name field shall contain the pathname of the file. The
length of this field in octets is the value of c_namesize.
If a filename is found on the medium that would create an invalid
pathname, it is implementation-defined whether the data from the
file is stored on the file hierarchy and under what name it is
stored.
All characters shall be represented in the ISO/IEC 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-defined
encodings of these characters shall be provided for interchange
purposes. However, the pax utility shall never create filenames
on the local system that cannot be accessed via the procedures
described previously in this volume of POSIX.1‐2017. If a
filename is found on the medium that would create an invalid
filename, it is implementation-defined whether the data from the
file is stored on the local file system and under what name it is
stored. The pax utility may choose to ignore these files as long
as it produces an error indicating that the file is being
ignored.
cpio File Data
Following c_name, there shall be c_filesize octets of data.
Interpretation of such data occurs in a manner dependent on the
file. For regular files, the data shall consist of the contents
of the file. For symbolic links, the data shall consist of the
contents of the symbolic link. If c_filesize is zero, no data
shall be contained in c_filedata.
When restoring from an archive:
* If the user does not have appropriate privileges to create a
file of the specified type, pax shall ignore the entry and
write an error message to standard error.
* Only regular files and symbolic links 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 shall be restored.
* If a user does not have appropriate privileges to set a
particular mode flag, the flag shall be ignored. Some of the
mode flags in the archive format are not mentioned elsewhere
in this volume of POSIX.1‐2017. If the implementation does
not support those flags, they may be ignored.
cpio Special Entries
FIFO special files, directories, and the trailer shall be
recorded with c_filesize equal to zero. Symbolic links shall be
recorded with c_filesize equal to the length of the contents of
the symbolic link. For other special files, c_filesize is
unspecified by this volume of POSIX.1‐2017. The header for the
next file entry in the archive shall be written directly after
the last octet of the file entry preceding it. A header denoting
the filename TRAILER!!! shall indicate the end of the archive;
the contents of octets in the last block of the archive following
such a header are undefined.
