41–50 of 109 posts
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?
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.
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…
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!
Earlier 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…
See: the permanent undismissable red icon to "finish setting up your Apple TV with your iPhone"
> For some reason
Very informative!
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…
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…
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…
> 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.
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.
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 wil…
Earlier quoted context omitted.
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)?