bug in BSD tar?

[John-Mark Gurney]

Steven Hartland wrote this message on Tue, May 29, 2007 at 11:46 +0100:
> ----- 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.

Is the file incorrect when extracted?  or is this a mater of gtar throwing
an error because of the tar format, and an option to bsdtar could be provided
to change the output tar format?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."