5

POSIX tar archives contain POSIX headers as "dummy" files named @PaxHeader. 7zip dutifully extracts them, and they all collide, since they are all named the same. 7z then complains about the file being in use, and finishes with errors. It does extract other files, and the extended headers are of no use on Windows anyway.

This problem arose in the context of extracting Qt .tar.xz archives when building Qt on Windows. The .tar.xz files are more compact than the .zip files, and it helps to reduce load in CI environments, where Qt may be downloaded and rebuilt often.

Is there a way to work around that?

Improve this question
3
  • From 21.07 @PaxHeaders seem to be dealt with correctly. I cannot find anything which mentions this in the changelog, but upgrading 7Zip from 19.00 to 21.07, fixed this, for me.
    – SiHa
    Commented May 12, 2022 at 9:23
  • I still see @PaxHeaders in 7z 21.07, but not in all tar archives, so I might have to do with how it was made and perhaps tar versions. I my case tar 1.34 (Linux) using tar --create --directory="dirA" "fileA" --directory="dirB" "fileB" > output.tar
    – MrCalvin
    Commented Apr 6, 2023 at 15:37
  • Creating the tarball using the tar option --format=gnu or --format=gnu fix the problem. I read somewhere that OpenSUSE default to --format=posix and using that format will show PaxHeaders in 7z
    – MrCalvin
    Commented Apr 6, 2023 at 15:57

2 Answers 2

Reset to default
3

tar.exe installed with "Git for Windows" can handle POSIX tarballs.

A lot of tar.exe and other compression programs like 7-zip that can handle tarballs too will sometimes (not allways) fail with archives containing Paxheaders. In most of the programs there are parameters that make it very likely to oversee the errors when extracting POSIX tarballs. Possible errors are shortened filenames and filenames without extensions (maybe some more).

tar.exe from "Git for Windows" can be used "stand-alone", i.e. outside git-bash in a windows command file or at the prompt. Best solution is to use full path to your installation:

C:\Program Files\Git\usr\bin\tar.exe -xf archive.tar.gz

The path to your git installation might be different depending on your installation. Be sure to use the right tar.exe.

which tar.exe

or

where tar.exe

might be helpfull to figure out.

Improve this answer
1

When listed with 7z l, these .tar archives contain a multitude of identically named files called .\.\@PaxHeader. Adding this file name to an exclude list given to 7z solves the problem.

The excludes can be provided either on the command line, i.e. "-x.\.\@PaxHeader", or in an exclude list file, e.g. [email protected], where the my.excludes file contains at least the .\.\@PaxHeader line.

Improve this answer
3
  • 3
    This is no propper solution. In certain constellations you will loose information (like fileextention or part of the filename) that is stored within the Paxheader. With some tarballs ././@PaxHeader should be someting like ./paxheaders.*
    – Christian4145
    Commented Feb 24, 2021 at 19:37
  • 1
    @Christian4145 It's certainly not a universal solution, but it works - or at least worked not long ago - in the context of Qt, and that was my immediate concern. It's usually easy to detect failures: since those are source archives, the build fails if something important gets messed up in extraction - although a passing build is not always a guarantee.
    – Kuba hasn't forgotten Monica
    Commented Aug 23, 2021 at 15:23
  • 1
    This is not a solution, but an ugly hack. These headers can contain useful information. The full path is stored in the header, if it exceeds 100chars. Without this information they will simply be truncated.
    – SiHa
    Commented May 12, 2022 at 9:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .