Tar files made in macOS generate "xattr" errors when expanded in Linux

Per this 2018 page, GNU tar seems to work with SCHILY.* encoded xattrs, but not LIBARCHIVE.* ones:

* https://mgorny.pl/articles/portability-of-tar-features.html#...

* Via: https://github.com/mxmlnkn/ratarmount/issues/145

bsdtar ≥3.7.2 apparently adds both types to its files for maximum portability:

* https://github.com/libarchive/libarchive/pull/691/files#diff...

AFAICT, bsdtar will default to "ustar" format, but will auto-switch to "pax" if needed.

Ex-Apple engineer here. This is, for better or worse, just the way Apple approaches this type of problem. From Apple's perspective, this is the way to preserve Finder / Gatekeeper / metadata semantics. It avoids silent data loss when round-tripping archives between Macs. This behavior also maintains consistency with copyfile(3) (as well as the Archive Utility behavior).

Apple treats tar less like “portable Unix interchange” and more like “archive this filesystem object faithfully.” That is very Apple, and very libarchive. ;-)

This is probably going to get worse (as Apple continues to add macOS-specific metadata), so your workaround is very helpful.

I haven't tested it in a while, but at one point, setting the COPYFILE_DISABLE=1 env variable would disable the inclusion of macOS-specific metadata.

I use these settings when creating a tar file for deploy:

    tar --no-xattrs --no-mac-metadata -czf

We might also ask, why doesn't Linux also track such meta-data? Are Linux users not also subject to drive-by downloads impersonating valid files? Should we be one chmod a+x away from compromise?

Homebrew installs GNU tar as "gtar". On my M4 MacBook:

  $ which gtar
  gtar is /opt/homebrew/bin/gtar

You can either send stderr to /dev/null or use --warning=no-unknown-keyword to suppress them cleanly.

But still interesting nonetheless why they are added