Re: git archive generates tar with malformed pax extended attribute

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On 2019-05-25 at 20:46:16, Ævar Arnfjörð Bjarmason wrote:
> Solaris tar also complains about this. I've seen that for ages, but
> never thought to report it, I figured it was well-known.
> 
> When you "tar xf" an archive git-archive it complains:
> 
>     tar: pax_global_header: typeflag 'g' not recognized, converting to regular file
> 
> It will then extract the "pax_global_header" as if it were a file at the
> root of the archive. That file will look like this:
> 
>     $ wc -c x/pax_global_header
>       52 x/pax_global_header
>     $ cat x/pax_global_header
>     52 comment=$40_CHAR_SHA_1
> 
> Where $40_CHAR_SHA_1 is whatever commit this archive was produced from.

Ironically, for a long time the pax(1) utility shipped with Debian was
incapable of reading pax headers. There are various other utilities
(including 7-Zip) that don't understand them, and they invariably get
converted to regular files (since that's what the spec says to do). This
problem is well known to me, but I don't know if it's well known to
everyone.

In this case, I suspect Solaris has a pax(1) utility that works fine,
but nobody bothered to port that code to tar(1).

Usually the lack of support is because people prefer GNU tar archives
over actual POSIX tar and pax archives, so real-world archivers don't
see POSIX archives and don't handle the extensions properly.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]