Date: Sat, 18 Sep 2010 00:24:51 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: freebsd-hackers@freebsd.org, kaiw@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: ar(1) format_decimal failure is fatal? Message-ID: <F56D9CB9-E644-4279-8830-71292C880D9B@freebsd.org> In-Reply-To: <alpine.GSO.1.10.1009032036310.9337@multics.mit.edu> References: <alpine.GSO.1.10.1008281833470.9337@multics.mit.edu> <20100829201050.GA60715@stack.nl> <alpine.GSO.1.10.1009032036310.9337@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 17, 2010, at 9:01 PM, Benjamin Kaduk wrote:
> On Sun, 29 Aug 2010, Jilles Tjoelker wrote:
>=20
>> On Sat, Aug 28, 2010 at 07:08:34PM -0400, Benjamin Kaduk wrote:
>>> [...]
>>> building static egacy library
>>> ar: fatal: Numeric user ID too large
>>> *** Error code 70
>>=20
>>> This error appears to be coming from
>>> lib/libarchive/archive_write_set_format_ar.c , which seems to only =
have
>>> provisions for outputting a user ID in AR_uid_size =3D 6 columns.
> [...]
>>> It looks like this macro was so defined in version 1.1 of that file, =
with
>>> commit message "'ar' format support for libarchive, contributed by =
Kai
>>> Wang.". This doesn't make it terribly clear whether the 'ar' format
>>> mandates this length, or if it is an implementation decision...
There's no official standard for the ar format, only old
conventions and compatibility with legacy implementations.
>> I wonder if the uid/gid fields are useful at all for ar archives. Ar
>> archives are usually not extracted, and when they are, the current
>> user's values seem good enough. The uid/gid also prevent exactly
>> reproducible builds (together with the timestamp).
>=20
> GNU binutils has recently (well, March 2009) added a -D =
("deterministic") argument to ar(1) which sets the timestamp, uid, and =
gid to zero, and the mode to 644. If that argument is not given, =
linux's ar(1) happily uses my 8-digit uid as-is; the manual page seems =
to imply that it will handle 15 or 16 digits in that field.
Please send me a small example file... I don't think I've seen
this format variant. Maybe we can extend our ar(1) to support
this variant.
Personally, I wonder if it wouldn't make sense to just always
force the timestamp, uid, and gid to zero. I find it hard
to believe anyone is using ar(1) as a general-purpose archiving
tool. Of course, it should be trivial to add -D support to our ar(1).
> I propose that format_{decimal,octal}() return ARCHIVE_FAILED for =
negative input, and ARCHIVE_WARN for overflow. =
archive_write_ar_header() can then catch ARCHIVE_WARN from the =
format_foo functions and continue on, propagating the ARCHIVE_WARN =
return value at the end of its execution ...
This sounds entirely reasonable to me. I personally don't see much
advantage to distinguishing negative versus overflow, but certainly
have no objections to that part. Definitely ar(1) should not abort on
a simple ARCHIVE_WARN.
> Would (one of) you be willing to review a patch to that effect?
Happy to do so.=20
Cheers,
Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F56D9CB9-E644-4279-8830-71292C880D9B>