The archive format is not described. It is recognized that there
are several known ar formats, which are not compatible. The ar
utility is included, however, to allow creation of archives that
are intended for use only on one machine. The archive is
specified as a file, and it can be moved as a file. This does
allow an archive to be moved from one machine to another machine
that uses the same implementation of ar.
Utilities such as pax (and its forebears tar and cpio) also
provide portable ``archives''. This is a not a duplication; the
ar utility is included to provide an interface primarily for make
and the compilers, based on a historical model.
In historical implementations, the -q option (available on XSI-
conforming systems) is known to execute quickly because ar does
not check on whether the added members are already in the
archive. This is useful to bypass the searching otherwise done
when creating a large archive piece-by-piece. These remarks may
but need not remain true for a brand new implementation of this
utility; hence, these remarks have been moved into the RATIONALE.
BSD implementations historically required applications to provide
the -s option whenever the archive was supposed to contain a
symbol table. As in this volume of POSIX.1‐2017, System V
historically creates or updates an archive symbol table whenever
an object file is removed from, added to, or updated in the
archive.
The OPERANDS section requires what might seem to be true without
specifying it: the archive cannot truncate the filenames below
{NAME_MAX}. Some historical implementations do so, however,
causing unexpected results for the application. Therefore, this
volume of POSIX.1‐2017 makes the requirement explicit to avoid
misunderstandings.
According to the System V documentation, the options -dmpqrtx are
not required to begin with a <hyphen-minus> ('-'). This volume
of POSIX.1‐2017 requires that a conforming application use the
leading <hyphen-minus>.
The archive format used by the 4.4 BSD implementation is
documented in this RATIONALE as an example:
A file created by ar begins with the ``magic'' string
"!<arch>\n". The rest of the archive is made up of
objects, each of which is composed of a header for a file,
a possible filename, and the file contents. The header is
portable between machine architectures, and, if the file
contents are printable, the archive is itself printable.
The header is made up of six ASCII fields, followed by a
two-character trailer. The fields are the object name (16
characters), the file last modification time (12
characters), the user and group IDs (each 6 characters),
the file mode (8 characters), and the file size (10
characters). All numeric fields are in decimal, except for
the file mode, which is in octal.
The modification time is the file st_mtime field. The user
and group IDs are the file st_uid and st_gid fields. The
file mode is the file st_mode field. The file size is the
file st_size field. The two-byte trailer is the string
"`<newline>".
Only the name field has any provision for overflow. If any
filename is more than 16 characters in length or contains
an embedded space, the string "#1/" followed by the ASCII
length of the name is written in the name field. The file
size (stored in the archive header) is incremented by the
length of the name. The name is then written immediately
following the archive header.
Any unused characters in any of these fields are written
as <space> characters. If any fields are their particular
maximum number of characters in length, there is no
separation between the fields.
Objects in the archive are always an even number of bytes
long; files that are an odd number of bytes long are
padded with a <newline>, although the size in the header
does not reflect this.
The ar utility description requires that (when all its members
are valid object files) ar produce an object code library, which
the linkage editor can use to extract object modules. If the
linkage editor needs a symbol table to permit random access to
the archive, ar must provide it; however, ar does not require a
symbol table.
The BSD -o option was omitted. It is a rare conforming
application that uses ar to extract object code from a library
with concern for its modification time, since this can only be of
importance to make. Hence, since this functionality is not
deemed important for applications portability, the modification
time of the extracted files is set to the current time.
There is at least one known implementation (for a small computer)
that can accommodate only object files for that system,
disallowing mixed object and other files. The ability to handle
any type of file is not only historical practice for most
implementations, but is also a reasonable expectation.
Consideration was given to changing the output format of ar -tv
to the same format as the output of ls -l. This would have made
parsing the output of ar the same as that of ls. This was
rejected in part because the current ar format is commonly used
and changes would break historical usage. Second, ar gives the
user ID and group ID in numeric format separated by a <slash>.
Changing this to be the user name and group name would not be
correct if the archive were moved to a machine that contained a
different user database. Since ar cannot know whether the archive
was generated on the same machine, it cannot tell what to report.
The text on the -ur option combination is historical practice—
since one filename can easily represent two different files (for
example, /a/foo and /b/foo), it is reasonable to replace the file
in the archive even when the modification time in the archive is
identical to that in the file system.
