ar(1) format_decimal failure is fatal?
jilles at stack.nl
Sun Aug 29 20:10:53 UTC 2010
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).
More information about the freebsd-hackers