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.
show comments
mxmlnkn
The title seems misleading.
These are not errors. They are simply warnings about extended attributes being ignored when extracting files, which seems completely fine to me, and creating the tar without those extended attributes has exactly the same outcome, but throws away the metadata at archive time instead of extraction time.
Furthermore, this is not an Apple/macOS issue. The tool used is bsdtar, so it would also affect all BSD-variants that default to bsdtar/libarchive, and those systems also have extended attributes, e.g., for SELinux, which would get added to the TAR.
pier25
I use these settings when creating a tar file for deploy:
tar --no-xattrs --no-mac-metadata -czf
show comments
throw0101a
Per this 2018 page, GNU tar seems to work with SCHILY.* encoded xattrs, but not LIBARCHIVE.* ones:
AFAICT, bsdtar will default to "ustar" format, but will auto-switch to "pax" if needed.
show comments
nottorp
I don't see errors, just warnings about unknown metadata. It's annoying yes. But they aren't errors.
seba_dos1
> Why does it have those extra files?
> For some reason
Very informative!
albertzeyer
But these are not errors. These are just warnings you can ignore? It's not really so critical?
red_admiral
Why switch to a completely different tar and rewire the PATH when you could just set a shell alias? You'll need to edit .bashrc both times but there's no need to install a second tar to /opt to solve this.
angry_octet
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?
show comments
chmaynard
Homebrew installs GNU tar as "gtar". On my M4 MacBook:
$ which gtar
gtar is /opt/homebrew/bin/gtar
show comments
raffraffraff
Would this ever affect me if I don't use many of MacOS built on tools? I brew install gnu equivalents make them all default. Just like how I also don't use most of their desktop environment stuff, and instead use rectangle, hammerspoon, karabiner to make it feel more like the Linux desktop I wish I could use at work.
mg794613
Oh Arul John, just because you don't understand, means it's a error.
What horrible advice also to download different tar versions, for something that should just be explained properly.
If it weren't for the "2024" in the title, I would have thought this to be a result from AI.
But it's not artificial intelligence. It's real stupidity.
bombcar
I'll admit that if I don't care about extended attributes (I never really do) I just use zip instead.
show comments
firesteelrain
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
kaiwn
Let me google the name of the author of this blog...
Oh...
LoganDark
> If you are using a Mac with an Apple Silicon M1, M2, M3 or M4 processor,
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.
The title seems misleading.
These are not errors. They are simply warnings about extended attributes being ignored when extracting files, which seems completely fine to me, and creating the tar without those extended attributes has exactly the same outcome, but throws away the metadata at archive time instead of extraction time.
Furthermore, this is not an Apple/macOS issue. The tool used is bsdtar, so it would also affect all BSD-variants that default to bsdtar/libarchive, and those systems also have extended attributes, e.g., for SELinux, which would get added to the TAR.
I use these settings when creating a tar file for deploy:
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.
I don't see errors, just warnings about unknown metadata. It's annoying yes. But they aren't errors.
> Why does it have those extra files?
> For some reason
Very informative!
But these are not errors. These are just warnings you can ignore? It's not really so critical?
Why switch to a completely different tar and rewire the PATH when you could just set a shell alias? You'll need to edit .bashrc both times but there's no need to install a second tar to /opt to solve this.
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:
Would this ever affect me if I don't use many of MacOS built on tools? I brew install gnu equivalents make them all default. Just like how I also don't use most of their desktop environment stuff, and instead use rectangle, hammerspoon, karabiner to make it feel more like the Linux desktop I wish I could use at work.
Oh Arul John, just because you don't understand, means it's a error.
What horrible advice also to download different tar versions, for something that should just be explained properly.
If it weren't for the "2024" in the title, I would have thought this to be a result from AI.
But it's not artificial intelligence. It's real stupidity.
I'll admit that if I don't care about extended attributes (I never really do) I just use zip instead.
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
Let me google the name of the author of this blog...
Oh...
> If you are using a Mac with an Apple Silicon M1, M2, M3 or M4 processor,
Don't forget the MacBook Neo's A18 Pro :)
How well does pax handle this?