From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 07:02:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66ACF1065692 for ; Wed, 20 Aug 2008 07:02:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9628FC21 for ; Wed, 20 Aug 2008 07:02:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.128] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m7K72Utv052349; Wed, 20 Aug 2008 00:02:30 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <48ABC1C3.2080105@freebsd.org> Date: Wed, 20 Aug 2008 00:03:31 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitry Andric References: <7d6fde3d0808172305h219231e2sad939eacb685414e@mail.gmail.com> <48A9D8D5.7050504@andric.com> <48ABB9FA.7050604@freebsd.org> In-Reply-To: <48ABB9FA.7050604@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , current@freebsd.org Subject: Re: Possible regression with 200807 amd64 snapshot CD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 07:02:34 -0000 Tim Kientzle wrote: > Dimitry Andric followed up with: > >> It's the same with 8.0-CURRENT-200807-i386-disc1.iso. Even GNU cpio >> doesn't eat the files (for example base.??): >> >> cpio: Malformed number 000755 cpio: Malformed number 000000 [...] > >> While GNU cpio shows something completely different: >> >> dr-sr-s--T 1 0 root 0 Feb 7 2006 ./ >> dr-sr-s--T 1 0 root 0 Feb 7 2006 ./bin/ >> dr-sr-s--T 1 0 root 0 Feb 7 2006 ./boot/ >> [...] > So far, I've only managed to reproduce the screwed-up output > with GNU cpio 2.9. I'm going to dig a little deeper to see > if this is really a bug in GNU cpio 2.9 or if there's some error > in the data that all those other programs are overlooking. I found it: GNU cpio 2.9 has broken support for reading standard ustar archives. The guilty code is the "from_ascii" routine in copyin.c which is invoked by the tar handler to parse octal numbers. It will skip leading spaces, but rejects the trailing space/null combination traditionally used to terminate the mode field in tar archives. (This termination is prescribed by tar.5 in 2.10BSD and explicitly permitted by SUSv2-1997.) GNU cpio 2.6 apparently does not have this bug; I don't have other versions of GNU cpio available to test this with. Tim