Re: git archive generates tar with malformed pax extended attribute

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 25, 2019, 21:19 UTC
Message-ID: <20190525211942.GE8616@genre.crustytoothpaste.net>
In-Reply-To: <878suufejr.fsf@evledraar.gmail.com>

On 2019-05-25 at 20:46:16, Ævar Arnfjörð Bjarmason wrote:

Show 16 quoted lines

> 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