I'll admit that if I don't care about extended attributes (I never really do) I just use zip instead.
Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
31–40 of 109 posts
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#32We 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?
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.
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.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#33Earlier quoted context omitted.
.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.
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.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#34Earlier 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…
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!
Are the xattr / chattr / umask checksums rolled into the main data fork content or are they hashed separately (or not at all)?
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#35Homebrew installs GNU tar as "gtar". On my M4 MacBook: $ which gtar gtar is /opt/homebrew/bin/gtar
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.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#36We 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?
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.
It’s not blunting a tool, it’s sheathing it. Modern software requires too much proxied trust for this attitude to work.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#37Earlier quoted context omitted.
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, neve…
> 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…
> 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.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#38Ex-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.
> 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
Linux developers already do. Using a BSD can already be a pain in the arse, thanks to (often poorly thought out) Linux-isms cropping up everywhere.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#39Earlier quoted context omitted.
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.
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".
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.
Re: Tar Files Created on macOS Display Errors When Extracting on Linux (2024)
#40Earlier quoted context omitted.
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.
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.
then we, the very small minority, want a button to disable that help.