ar(1) format_decimal failure is fatal?

[Tim Kientzle]

On Sep 17, 2010, at 9:01 PM, Benjamin Kaduk wrote:

> On Sun, 29 Aug 2010, Jilles Tjoelker wrote:
> 
>> 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
>> 
>>> 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 = 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).
> 
> 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. 

Cheers,

Tim