ar(1) format_decimal failure is fatal?

[Jilles Tjoelker]

On Sat, Aug 28, 2010 at 07:08:34PM -0400, Benjamin Kaduk wrote:
> I've been working on fixing the OpenAFS network filesystem client for 
> FreeBSD, and it's at the point where I want to use the lazy man's 
> filesystem stress test: buildworld.
> However, quite early in the process, I get the following error:
> >>> stage 1.1: legacy release compatibility shims
> [...]
> ===> tools/build (obj,includes,depend,all,install)
> [...]
> 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.
> Now, AFS user IDs are not tied to unix IDs; there is a separate protection 
> server whose "pts" IDs are used for access control; these pts IDs are tied 
> to kerberos authentication.  In this case, I was authenticated as 
> daemon/freebuild.mit.edu at ATHENA.MIT.EDU, with pts ID 33554737, which needs 
> 8 columns to display.

> 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, so I get to 
> ask: what reasoning (if any) was behind this choice?  Would anything break 
> if it was bumped up to a larger size?  Are there other options for a 
> workaround in my AFS environment?

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).

-- 
Jilles Tjoelker