Re: Possible regression with 200807 amd64 snapshot CD

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