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 6 hours ago | parent | next [-]

> 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.

▲

Arainach 27 minutes ago | parent | next [-]

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"

▲

crazygringo 2 hours ago | parent | prev | next [-]

> 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.

	▲	dlenski 24 minutes ago \| parent [-]
		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 metadata with Apple's own tar, though.

▲

Joker_vD 4 hours ago | parent | prev | next [-]

> 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.

▲

amarant 5 hours ago | parent | prev [-]

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!

	▲	dented42 an hour ago \| parent \| next [-]
		So it sounds like you don’t get the exact version you want because metadata is thrown away.
	▲	JoshTriplett 5 hours ago \| parent \| prev \| next [-]
		Yeah, Nix-like distributions (e.g. guix, lix) do for Linux systems what some language package managers (e.g. cargo) do for individual projects.
	▲	altairprime 3 hours ago \| parent \| prev [-]
		Are the xattr / chattr / umask checksums rolled into the main data fork content or are they hashed separately (or not at all)?

▲

saghm 26 minutes ago | parent | prev | next [-]

If you think that most people who run the tar command are assuming it will work like a tape archive, you'll probably be the one surprised

▲

taftster 6 hours ago | parent | prev [-]

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

Yes please.

▲

ryandrake 5 hours ago | parent [-]

.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.

▲

gerdesj 5 hours ago | parent | next [-]

thumbs.db and those weird MS alternative stream files for recording origination.

filesystem attributes are for decorating files with meaning. Anything else that attempts to use filesystems in "interesting" ways is silly.

Apple and MS really ought to consider why they do this sort of fragile, idiosyncratic nonsense.

▲

Joker_vD 5 hours ago | parent [-]

But... thumbs.db is precisely not an "attempt to use filesystems in "interesting" ways" — it's literally a just hidden file with previews stored in it. Storing the preview in the alternative stream of the file with the picture itself would be "an interesting way".

	▲	mook 2 hours ago \| parent \| next [-]
		In the particular case of thumbs.db, storing them in NTFS alternate data streams would have been a good idea; they're essentially caches for the main data stream, so if they fail to copy to different filesystems it's totally fine. Of course, that wasn't viable because 1) IIRC that was before the widespread adoption of NTFS, and 2) they probably still need the cache somewhere for vFAT USB drives.
	▲	kstrauser 5 hours ago \| parent \| prev [-]
		Agreed. Where else would you put that stuff? It’s gotta go somewhere, and this is the least surprising place IMO. Anywhere else would have to be a parallel store that follows filesystem mounts and unmounts, renaming directories, etc so that it alway perfectly mirrors the thing it’s configuring.

▲

emmelaich 4 hours ago | parent | prev [-]

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

	▲	ajxs 3 hours ago \| parent [-]
		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.