From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 29 20:10:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE78A106566B; Sun, 29 Aug 2010 20:10:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id B15D78FC17; Sun, 29 Aug 2010 20:10:52 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 6FCC335A883; Sun, 29 Aug 2010 22:10:50 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 5B44E172CC; Sun, 29 Aug 2010 22:10:50 +0200 (CEST) Date: Sun, 29 Aug 2010 22:10:50 +0200 From: Jilles Tjoelker To: Benjamin Kaduk Message-ID: <20100829201050.GA60715@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, kientzle@freebsd.org, kaiw@freebsd.org Subject: Re: ar(1) format_decimal failure is fatal? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 20:10:53 -0000 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@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