bug in BSD tar?

[Steven Hartland]

----- Original Message ----- 
From: "Colin Percival" <cperciva at freebsd.org>
>> ----- Original Message ----- From: "Colin Percival" <cperciva at freebsd.org>
>>>> tar -xvzf test.tar.gz
>>>> tar: Ignoring unknown extended header keyword `SCHILY.dev'
>>>> tar: Ignoring unknown extended header keyword `SCHILY.ino'
>>>> tar: Ignoring unknown extended header keyword `SCHILY.nlink'
>>>> cantiquedeno\353l1_loop.wav
>>>> tar: Error exit delayed from previous errors
>>>
>>> This looks like fairly typical symptoms of gnutar being broken.  What
>>> makes you think that the archive created by BSD tar was invalid?
>> 
>> As a filename should have no bearing on what extended headers
>> are set.
> 
> Why not?  In this case, bsdtar is detecting that the file name contains
> non-7-bit-ascii characters and is emitting a pax header for that reason;
> and since it can't suppress the pax header entirely, it goes ahead and
> emits the "not vital but potentially useful" headers for the device #,
> inode #, number of links, and high precision timestamps.
> 
> I still see no evidence that bsdtar is doing anything wrong.

I suppose this then comes down to the fact that gnu tar is the prevalent
version out there and as such with BSD creating archives which are
incompatible with that leads to problems. From our side we'll have to
switch to using gnutar until this issue is resolved as we need to ensure
compatibility.

    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.