Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Aug 2010 19:08:34 -0400 (EDT)
From:      Benjamin Kaduk <kaduk@MIT.EDU>
To:        kientzle@freebsd.org, kaiw@freebsd.org
Cc:        freebsd-hackers@freebsd.org
Subject:   ar(1) format_decimal failure is fatal?
Message-ID:  <alpine.GSO.1.10.1008281833470.9337@multics.mit.edu>

next in thread | raw e-mail | index | archive | help
Hi all,

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@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?

Thanks for your thoughts,

Ben Kaduk



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1008281833470.9337>