Date: Wed, 20 Aug 2008 00:03:31 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Dimitry Andric <dimitry@andric.com> Cc: Garrett Cooper <yanefbsd@gmail.com>, current@freebsd.org Subject: Re: Possible regression with 200807 amd64 snapshot CD Message-ID: <48ABC1C3.2080105@freebsd.org> In-Reply-To: <48ABB9FA.7050604@freebsd.org> References: <7d6fde3d0808172305h219231e2sad939eacb685414e@mail.gmail.com> <48A9D8D5.7050504@andric.com> <48ABB9FA.7050604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48ABC1C3.2080105>