From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 08:02:33 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 C363D1065670; Sat, 18 Sep 2010 08:02:33 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D027D8FC19; Sat, 18 Sep 2010 08:02:32 +0000 (UTC) Received: from [10.123.2.180] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o8I7Ops0073710; Sat, 18 Sep 2010 07:24:51 GMT (envelope-from kientzle@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 18 Sep 2010 00:24:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100829201050.GA60715@stack.nl> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1081) Cc: freebsd-hackers@freebsd.org, kaiw@freebsd.org, Jilles Tjoelker 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: Sat, 18 Sep 2010 08:02:33 -0000 On Sep 17, 2010, at 9:01 PM, Benjamin Kaduk wrote: > On Sun, 29 Aug 2010, Jilles Tjoelker wrote: >=20 >> On Sat, Aug 28, 2010 at 07:08:34PM -0400, Benjamin Kaduk wrote: >>> [...] >>> building static egacy library >>> ar: fatal: Numeric user ID too large >>> *** Error code 70 >>=20 >>> 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 =3D 6 columns. > [...] >>> 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... There's no official standard for the ar format, only old conventions and compatibility with legacy implementations. >> 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). >=20 > GNU binutils has recently (well, March 2009) added a -D = ("deterministic") argument to ar(1) which sets the timestamp, uid, and = gid to zero, and the mode to 644. If that argument is not given, = linux's ar(1) happily uses my 8-digit uid as-is; the manual page seems = to imply that it will handle 15 or 16 digits in that field. Please send me a small example file... I don't think I've seen this format variant. Maybe we can extend our ar(1) to support this variant. Personally, I wonder if it wouldn't make sense to just always force the timestamp, uid, and gid to zero. I find it hard to believe anyone is using ar(1) as a general-purpose archiving tool. Of course, it should be trivial to add -D support to our ar(1). > I propose that format_{decimal,octal}() return ARCHIVE_FAILED for = negative input, and ARCHIVE_WARN for overflow. = archive_write_ar_header() can then catch ARCHIVE_WARN from the = format_foo functions and continue on, propagating the ARCHIVE_WARN = return value at the end of its execution ... This sounds entirely reasonable to me. I personally don't see much advantage to distinguishing negative versus overflow, but certainly have no objections to that part. Definitely ar(1) should not abort on a simple ARCHIVE_WARN. > Would (one of) you be willing to review a patch to that effect? Happy to do so.=20 Cheers, Tim