Author CAM-Gerlach
Recipients CAM-Gerlach, lars.gustaebel, serhiy.storchaka
Date 2019-03-13.19:33:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In general, since pax is a backwards-compatible superset of the standard, portable ustar unlike the vendor-specific GNU format that even GNU tar itself no longer recommends in favor of switching to pax by default, it is to my understanding essentially always the better choice. The only exception would be systems that support GNU tar but not POSIX 2001 and where the limitations of the old ustar must be bypassed, which as far I'm aware is basically just really old (>10-15 years) GNU/Linux.

NetBSD and OpenBSD both use bsdtar implementations, which as far as I could find means they support the POSIX 2001-standard pax format, and (unless they use libarchive which supports all three) likely *don't* support the current GNU format which is specific to GNU tar. Even if they don't, their ustar support means they can read pax archives as legacy ustar archives (as pax is backwards-compatible), while the same is not necessarily true of GNU tar archives. Therefore, pax is strictly a better choice than GNU or ustar.

Most other programming languages I could find did not have internal/standard library implementations, instead relying on the aforementioned libraries or varying third party packages:

* For C/C++, Libarchive and GNU tar are the modern two heavy hitters, and they both have supported it for a very long long. Modern version of old-style bsdtar should, but if not then they don't support GNU tar either. These are commonly used when needed with C/C++, or programmers implement their own bespoke solutions.
* Libtar (C) does not, but it hasn't been updated for 6 years (and has been in minimal maintenance mode for over 15) so I'm not sure its really relevant anymore. Virtually any platform will also have one of the previous.
* The major implementation for Java, Apache Commons Compress, added support for both pax and GNU in its 1.2 version, back in 2011 (8 years ago)
* R uses the system's tar executable (or bundled modern tar), so will have the same support as that (i.e. any remotely modern system should be compatible). Their documentation explicitly recommends against GNU tar in favor of pax or ustar instead for portability:
* git-archive uses pax exclusively
* PHP supports ustar only, not pax or GNU; in that case pax is generally the more compatible of the two extended formats
* The node-tar library, the apparent standard for Javascript, support it
* The standard tar package for Go supports it
* What seems to be the major current implementation for C#, SharpZipLib, supports it
* Ruby has no apparent standard implementation; a few third-party libraries have a mix of support
Date User Action Args
2019-03-13 19:33:33CAM-Gerlachsetrecipients: + CAM-Gerlach, lars.gustaebel, serhiy.storchaka
2019-03-13 19:33:33CAM-Gerlachsetmessageid: <>
2019-03-13 19:33:33CAM-Gerlachlinkissue36268 messages
2019-03-13 19:33:33CAM-Gerlachcreate