Caution is advised when using the -a option to append to a cpio
format archive. If any of the files being appended happen to be
given the same c_dev and c_ino values as a file in the existing
part of the archive, then they may be treated as links to that
file on extraction. Thus, it is risky to use -a with cpio format
except when it is done on the same system that the original
archive was created on, and with the same pax utility, and in the
knowledge that there has been little or no file system activity
since the original archive was created that could lead to any of
the files appended being given the same c_dev and c_ino values as
an unrelated file in the existing part of the archive. Also, when
(intentionally) appending additional links to a file in the
existing part of the archive, the c_nlink values in the modified
archive can be smaller than the number of links to the file in
the archive, which may mean that the links are not preserved on
extraction.
The -p (privileges) option was invented to reconcile differences
between historical tar and cpio implementations. In particular,
the two utilities use -m in diametrically opposed ways. The -p
option also provides a consistent means of extending the ways in
which future file attributes can be addressed, such as for
enhanced security systems or high-performance files. Although it
may seem complex, there are really two modes that are most
commonly used:
-p e ``Preserve everything''. This would be used by the
historical superuser, someone with all appropriate
privileges, to preserve all aspects of the files as they
are recorded in the archive. The e flag is the sum of o
and p, and other implementation-defined attributes.
-p p ``Preserve'' the file mode bits. This would be used by
the user with regular privileges who wished to preserve
aspects of the file other than the ownership. The file
times are preserved by default, but two other flags are
offered to disable these and use the time of extraction.
The one pathname per line format of standard input precludes
pathnames containing <newline> characters. Although such
pathnames violate the portable filename guidelines, they may
exist and their presence may inhibit usage of pax within shell
scripts. This problem is inherited from historical archive
programs. The problem can be avoided by listing filename
arguments on the command line instead of on standard input.
It is almost certain that appropriate privileges are required for
pax to accomplish parts of this volume of POSIX.1‐2017.
Specifically, creating files of type block special or character
special, restoring file access times unless the files are owned
by the user (the -t option), or preserving file owner, group, and
mode (the -p option) all probably require appropriate privileges.
In read mode, implementations are permitted to overwrite files
when the archive has multiple members with the same name. This
may fail if permissions on the first version of the file do not
permit it to be overwritten.
The cpio and ustar formats can only support files up to
8589934592 bytes (8 ∗ 2^30) in size.
When archives containing binary header information are listed ,
the filenames printed may cause strange behavior on some
terminals.
When all of the following are true:
1. A file of type directory is being placed into an archive.
2. The ustar archive format is being used.
3. The pathname of the directory is less than or equal to 155
bytes long (it will fit in the prefix field in the ustar
header block).
4. The last component of the pathname of the directory is longer
than 100 bytes long (it will not fit in the name field in the
ustar header block).
some implementations of the pax utility will place the entire
directory pathname in the prefix field, set the name field to an
empty string, and place the directory in the archive. Other
implementations of the pax utility will give an error under these
conditions because the name field is not large enough to hold the
last component of the directory name. This standard allows
either behavior. However, when extracting a directory from a
ustar format archive, this standard requires that all
implementations be able to extract a directory even if the name
field contains an empty string as long as the prefix field does
not also contain an empty string.
