Live data from Hacker News

Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

aruljohn.com

51–60 of 109 posts

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#51
post #47

Earlier quoted context omitted.

> The question is always whose surprise. I think that the surprise of more data than expected is more desirable than the surprise of data loss. So in this case, it seems like the safe choice.

Agreed. I usually hate on Apple, and its terribly ancient utilities and gratuitous incompatibility with modern Linux utilities, motivated by hatred of the GPL license. But in this case, I think what it's doing is… basically fine? "Tar should faithfully reproduce the semantics of the source filesystem" is a perfectly reasonable starting point. Ideally there would be a documented way to turn off the Apple-specific meta…

From tar(1):

     --no-mac-metadata
             (x mode only) Mac OS X specific.  Do not archive or extract ACLs
             and extended file attributes using copyfile(3) in AppleDouble
             format.  This is the reverse of --mac-metadata.  and the default
             behavior if tar is run as non-root in x mode.

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#52
post #49

Earlier quoted context omitted.

Are the xattr / chattr / umask checksums rolled into the main data fork content or are they hashed separately (or not at all)?

IIRC Nix is checksummed in the hash of the source of the content, not the results.

Hash of a normalization of the derivation, so this roughly means source, dependencies and the ‘build recipe’. The exception are fixed-output derivations, which are typically content-hashed.

That said, a lot of work is done in content-addressed hashing, but AFAIK it’s not the default yet.

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#53

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?

Tar on linux will. e.g. selinux attrs and other xattrs. Open question, is it worth attempting to main these semantics between mac and linux.

No,

I just assume apple will break the behavior when they want to.

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#55
post #35
post #27

Earlier quoted context omitted.

Ive installed the gtar formula and aliased it to tar. Cant be bothered to memorize the differences between macOS tar and unix tar, especially when the latter is considered to be the de facto standard

> and unix tar It's in the name: GNU's Not Unix.

But, ironically enough, MacOS _is_ Unix:

https://www.opengroup.org/openbrand/register/

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#56
post #11

Earlier quoted context omitted.

It's a good attitude to have, in my opinion. Portability is overrated. Linux developers should be doing a lot more of this. We should be making everything work better for us without caring how it's going to impact other irrelevant platforms. Let the people who actually care about those platforms worry about such things.

It would at least be nice if there was a way to keep apple users from shitting all over the filesystem with remote mounts and ds_store files. Perhaps by automatically unmounting if one is detected.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#57

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 inter…

Funnily enough, I got the error message and asked Claude Code, and it replied;

    The warning can be suppressed by `--no-xattrs --no-mac-metadata`.
then just edited the code as

    -  tar czf dist.tar.gz dist
    +  COPYFILE_DISABLE=1 tar czf dist.tar.gz dist

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#58
post #33

Earlier quoted context omitted.

OTOH, If you want the information contained in those files, where else would you save it?

To me it seems more sensible to store information relevant only to this OS in a specific cache somewhere within that OS. It would even make cache-like functionality such as evicting old entries super easy.

There are some tradeoffs. Like if you used a usb and set up folder colours or any of the other things stored in the file, they would not move along with the usb when used on another computer.

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#59

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 inter…

It's a good attitude to have, in my opinion. Portability is overrated. Linux developers should be doing a lot more of this. We should be making everything work better for us without caring how it's going to impact other irrelevant platforms. Let the people who actually care about those platforms worry about such things.

Portability of tar archives at least. We should have some like .zip which are standardised and allow some like tar to be faithful replicas of exactly how the OS stores data.

Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)

#60

Earlier quoted context omitted.

> Arguably, principle of least surprise is very Apple. Principle of least surprise is good engineering practice. The question is always whose surprise. Someone who expects tar to behave like other UNIX systems is going to be surprised by this. Someone who expects tar on Apple to have perfect fidelity would be surprised by not-this. I increasingly feel like build systems should never be relying on any "native" utiliti…

Apple is always surprised that non-Apple devices exist. See: the permanent undismissable red icon to "finish setting up your Apple TV with your iPhone"

Apple can't control non-Apple devices. They can only control their own. So this makes perfect sense.
Post reply on HN