Date: Mon, 28 May 2007 20:18:59 -0700 From: Colin Percival <cperciva@freebsd.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: bug in BSD tar? Message-ID: <465B9BA3.30905@freebsd.org> In-Reply-To: <003701c7a187$bc8f8e10$b6db87d4@multiplay.co.uk> References: <005d01c7a169$b48c7390$b6db87d4@multiplay.co.uk> <465B4C2B.6060104@freebsd.org> <003701c7a187$bc8f8e10$b6db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Steven Hartland wrote: > ----- Original Message ----- From: "Colin Percival" <cperciva@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. Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?465B9BA3.30905>