Hi there!

I'm reporting this as a minor differential in libarchive's handling of pax-style tar streams. I say "minor" because it's not common in practice for pax streams to use global extensions, much less records in global extensions that affect per-member state (like filenames or linknames). However, pax allows this, and a conforming implementation should probably honor it (or explicitly reject it).

In practice, what this means is that libarchive and other pax parsers disagree about the filename (and other attributes) of a record. As a minimal example, consider the following stream of pax/ustar blocks:

typeflag=g path=global.txt
typeflag=0 path=raw.txt contents="X"

libarchive extracts this as raw.txt with contents X, while GNU tar and Python's tarfile both extract it as global.txt with contents X.

Here's an MRE of the same behavior (zipped to get GitHub to accept it): libarchive-global-pax-path.tar.zip

Example output (and versus Python's tarfile):

% tar -tf reproducers/dif-11-libarchive-global-pax-path.tar                                                                                                                                                                             
raw.txt
% python3 -m tarfile --list reproducers/dif-11-libarchive-global-pax-path.tar                                                                                                       
global.txt 

I believe this corresponds to the following TODO:

And the relevant normative part of POSIX pax:

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pax.html#tag_20_94_13_03:~:text=Represents%20global%20extended,transporting%20the%20archive.