[12652] in Athena Bugs
[Helen Bragg: Reqid: s15915]
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Sep 23 19:17:40 1994
Date: Fri, 23 Sep 1994 19:17:32 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: bugs@MIT.EDU
Cc: reidmp@MIT.EDU
The following bug should be forwarded back to Cygnus --- in their Solaris
94Q2 release, their "ar" and "ranlib" utilities produce .a files which
do not conform to the SysV standards for the "ar" format. This causes
Purify to toss its cookies, which isn't good. :-)
- Ted
------- Forwarded Message
Date: Fri, 23 Sep 1994 15:24:09 -0700
From: bragg@pure.com (Helen Bragg)
To: tytso@MIT.EDU, support@pure.com
Subject: Reqid: s15915
Reply-To: support@pure.com
Theodore,
Here is the "ar" format information you requested. We will fix this problem
in a release after Purify 3.0.
-Helen
Here's the problem. The man page for describing the archive file format states:
struct ar_hdr /* file member header */
{
char ar_name[16]; /* '/' terminated file member name */
char ar_date[12]; /* file member date */
char ar_uid[6]; /* file member user identification */
char ar_gid[6]; /* file member group identification */
char ar_mode[8]; /* file member mode (octal) */
char ar_size[10]; /* file member size */
char ar_fmag[2]; /* header trailer string */
};
All information in the file member headers is in printable
ASCII. The numeric information contained in the headers is
stored as decimal numbers (except for ar_mode which is in
octal). Thus, if the archive contains printable files, the
archive itself is printable.
If the file member name fits, the ar_name field contains the
name directly, and is terminated by a slash (/) and padded
with blanks on the right. If the member's name does not
fit, ar_name contains a slash (/) followed by a decimal
representation of the name's offset in the archive string
table described below.
And later it says
If some archive member's name is more than 15 bytes long, a
special archive member contains a table of file names, each
followed by a slash and a new-line. This string table
member, if present, will precede all ``normal'' archive
members. The special archive symbol table is not a ``nor-
mal'' member, and must be first if it exists. The ar_name
entry of the string table's member header holds a zero
length name ar_name[0]=='/', followed by one trailing slash
(ar_name[1]=='/'), followed by blanks (ar_name[2]==' ',
etc.). Offsets into the string table begin at zero. Exam-
ple ar_name values for short and long file names appear
below.
Offset +0 +1 +2 +3 +4 +5 +6 +7 +8 +9
0 f i l e _ n a m e _
10 s a m p l e / \n l o
20 n g e r f i l e n a
30 m e x a m p l e / \n
Member Name ar_name Note
short-name short-name/ Not in string table
file_name_sample /0 Offset 0 in string table
longerfilenamexample /18 Offset 18 in string table
This clearly states that long member names in the string table are terminated by
the pair "/\n". In the archive that you sent us, the long member names are
terminated by a "\n" without the "/".
As you note, the existing Sun utilities accept this format (although they do not
create files with this problem). Certainly Purify should be as forgiving.
Unfortunately, it is too late to make the necessary change to Purify 3.0 -- the
bits are already off at the duplicator -- but it will be fixed in future
versions.
------- End Forwarded Message
