TechPulseTechPulse
Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

56% Positive

Analyzed from 963 words in the discussion.

Trending Topics

#tar#should#apple#system#macos#files#least#file#linux#metadata

Discussion (32 Comments)Read Original on HackerNews

LatencyKills•4 days ago
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.

Terretta•1 day ago
Arguably, principle of least surprise is very Apple.

If I point "tape archive" at a file system, I want that file system archived to tape. And so, tar does.

If I don't, well, that's a fine option, and there's a fine option for that.

So it's less of a "workaround" or something that "gets worse", than, "No, I don't really want a tape archive of this filesystem, only of some of it." And that's supported.

That said, never seeing another .DS_Store should be a system-wide option!

JoshTriplett•about 3 hours ago
> 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" utilities from the host system, and should instead be bringing them in via dependencies. You can't have this problem if your packaging system pulls in a specific portable `tar` library.

amarant•about 2 hours ago
Nixos has a pretty solid solution to this issue: key your dependencies with checksums of the content. That way you get the best of both worlds: you always get the exact version you want, and you can share a copy of that exact version with other software that wants to use that exact version too!
Joker_vD•about 1 hour ago
> I increasingly feel like build systems should never be relying on any "native" utilities from the host system, and should instead be bringing them in via dependencies.

Well, you see, while this, frankly, applies not just to build systems but to most of software, the consensus in the community of distro-maintainers is that it's actually wrong: you should use your system's package manager, and tools it can install, and let it fiddle with the ambient environment and give you that delicious "path dependency". And if your distro's packaging environment doesn't allow to do the things you need (e.g. being able to install both mongodb 3.8 and mongodb 5.0, ideally at the same time, but okay, I can keep running apt remove/install over and over, but I do need to check if my app correctly handled the wire protocol changes), well, that's your problem for desiring strange things.

taftster•about 3 hours ago
> That said, never seeing another .DS_Store should be a system-wide option!

Yes please.

ryandrake•about 2 hours ago
.DS_Store, .fseventsd, .Spotlight-V100, .Trashes, and ._this and ._that

These can all die in a fire too, as far as I am concerned. macOS loves to treat the user's filesystem as its own personal garbage dump.

matheusmoreira•about 3 hours ago
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.
cozzyd•about 2 hours ago
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.
bombcar•about 1 hour ago
At least if you're using ZFS as the backing store and Samba, you can set vfs objects = catia fruit streams_xattr and similar config options to use extended attributes.
jmclnx•about 2 hours ago
To me, the big question is why Apple needs all these file attribute ? If the files are extracted OK, just ignore the errors :)
bombcar•about 1 hour ago
Apple has had multiple streams per file since the very beginning, and it can store useful and necessary information (the latter is quite rare now, as most things have sane defaults, but losing the extended attributes can lose things that can be annoying).
pier25•about 3 hours ago
I use these settings when creating a tar file for deploy:

    tar --no-xattrs --no-mac-metadata -czf
jherskovic•about 1 hour ago
I do this same thing too when building archives in macOS I will unpack on Linux later.
throw0101a•about 2 hours ago
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.

angry_octet•about 3 hours ago
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?
danielheath•about 2 hours ago
Yes, we should be.

My computer should run programs when I tell it to run them.

Don’t blunt _every_ tool just to make them harder to cut yourself on.

rtpg•about 1 hour ago
Increased metadata isn't tool blunting in itself though, even if MacOS uses it for being... annoying is one way of saying it.

Provenance information bundled into a file is not the worst idea in the world IMO. We have created/modified timestamps on files already, right? There's definitely the question of "why" but hey if more of my binaries just had at least a tag about who put them there that would be a win in my book.

Not an argument for doing what MacOS does, just an argument that the info would be nice to have.

angry_octet•about 2 hours ago
I hope you're in the very small minority of people who rigorously manage untrusted downloads and whitelist every binary, because you're operating an appliance from the 1970s, sticking a metal fork into an un-earthed toaster. Most people need help from their operating system.
Joker_vD•about 2 hours ago
I sincerely agree. By the way, thanks for lending your machine for my "Network-Retransmission-and-Compute-as-a-service" network.
emmelaich•about 1 hour ago
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.

bitfilped•about 2 hours ago
Should I be able to run files I download on my own computer? I think yes I should, hate fighting MacOS to do simple tasks because Apple engineers assume the end user has the average intelligence of an ostrich.
bombcar•about 1 hour ago
I'll admit that if I don't care about extended attributes (I never really do) I just use zip instead.
chmaynard•about 2 hours ago
Homebrew installs GNU tar as "gtar". On my M4 MacBook:

  $ which gtar
  gtar is /opt/homebrew/bin/gtar
fastily•about 1 hour ago
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
firesteelrain•about 3 hours ago
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