Steven Hartland wrote: > ----- Original Message ----- From: "Colin Percival" <[EMAIL PROTECTED]> >>> 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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"