TLDR: all standard applications for working with files are unaware of resource forks. This is confusing, and hurts new computer users. #consideredharmful
All apps designed for Macs by people who actually know what they are doing are resource fork aware, even though resource forks have gone out of fashion.
Like it was said before, resource forks have been around since the first version of the Macintosh (I believe MacOS was called "System" at that time), and it was a rather clever way to keep data such as dialog boxes, message strings and icons out of the executable file while keeping it a single file.
> In 15 years of working with Macs (as a programmer and as a semi-pro DAW/NLE user), I've never been confused once by them.
Gosh, are you saying that the common use of ADS was a common mac pattern and people very familiar with the history of macs would understand this well?
Do you really think that refutes the point that they're confusing to everyone else? While many OSs have implementations of ADS, almost no one uses them.
>Gosh, are you saying that the common use of ADS was a common mac pattern and people very familiar with the history of macs would understand this well?
It was quite common, yes, and even more extended in the past, but I'm saying something else: that noticing it and having issues with it wasn't that common. It's a leaky abstraction, but you don't often meet that leak.
Case in point TFA's issue. He has a zero-sized font file where all the data are in the resource leak. All fonts I've dealt with in OS X have been proper files, you can copy over to other FS normally.
>Do you really think that refutes the point that they're confusing to everyone else?
No, as I wrote: "It sure can be confusing (and I see how)".
But it's not that often that it has a chance to be confusing (at least in my experience -- but I've also not seen much discussion in support forums, questions from friends/colleagues with Macs etc about such as issues, whereas I've seen for many other issues).
>While many OSs have implementations of ADS, almost no one uses them.
Wouldn't that make them even MORE confusing in those OSs, the times they're finally used? As opposed to an OS that regularly uses them?
You act like that's not intentional. If it's a feature that's there for legacy reasons only and it's used as little as possible by the system, and not one iota more, why the heck should Finder, et al expose it to users? In the (very, very, very) rare case that a user actually needs to get into the resource fork of some antiquated file, that user (who is going to be very technical by definition, otherwise how the heck would they even stumble across such a file or care about what's in it?) can simply use the very widely known and documented command line tools or APIs for dealing with it. Anything more than that and you'd just be encouraging people to use a feature that you don't want anyone to use in the first place.
There's a difference between having a feature you want everyone to use, vs. having a feature that only exists for very specific legacy reasons in very specific systems-level backwards-compatibility scenarios, that you don't want anyone to use under any circumstances. Exposing the feature more than it already is exposed would be far more confusing and hurtful to new computer users, most of whom don't understand working with filesystems in general much less specific low-level filesystem features like resource forks.
All apps designed for Macs by people who actually know what they are doing are resource fork aware, even though resource forks have gone out of fashion.
Like it was said before, resource forks have been around since the first version of the Macintosh (I believe MacOS was called "System" at that time), and it was a rather clever way to keep data such as dialog boxes, message strings and icons out of the executable file while keeping it a single file.