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....@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
