[chetanahuja]

Conflating extattrs with HFS style resource forks doesn't really make sense.

Extended attributes are just that... attributes. They are not the main "data" of the file. Each and every unix file system has some attributes to begin with (permissions, timestamps etc.) and they vary from filesystem to filesystem (e.g., setuid bit, immutable bit etc.). User supplied attributes just extends this concept in a natural way. All the standard tools expect to be able to call open() on the file and start reading a stream of bytes assuming there's sufficient access. That's what a "file" is.

Moreover, it's not just unix as an isolated systems. Those expectations are baked into the structure of the entire Internet. When you receiving a "file" over any medium like email, web etc., you're expecting to receive the aforementioned stream of bytes. The attributes (or extended attributes) are not expected to accompany the file data as a general case.

Resource forks on the other hand just completely work against reasonable user expectations. The example given in the OP's post is one such instance. A font file that shows up as having zero bytes to every tool that works with files including tools that expect to transfer "files" over the internet. It's just broken by design.

[mdellabitta]

Just a datapoint: Macs have been sending files via the Internet with resource forks for a long time, basically since the invention of the Macintosh: https://en.wikipedia.org/wiki/BinHex

Resource forks are basically legacy from the original MacOS, and something that's being retained for compatibility, not something that's really a current design. The current replacement of resource forks is bundles, where a directory masquerades as a file in the GUI.

There are lots of reasons to hate on HFS+, but I wouldn't consider this the most important one.

[marssaxman]

It's not broken, it's just old. It's a legacy technology from the original Macintosh system released in 1984 - before it was even called "Mac OS". Your "reasonable user expectations" are conditioned by three decades of experience with systems that largely didn't exist when the Macintosh resource fork was designed.

[chetanahuja]

Yes the filesystem is from the 80's and from a period where Unix filesystem model had perhaps not gained the dominance that it did in later years. The question is why is it still being used in OSX 15 years after a complete redesign of the system around a Unix kernel?

[marssaxman]

They had to support HFS+ in order to convince existing users to upgrade. The first five releases of OS X had something called "Classic mode" which was basically an instance of OS 9 running as a process, so that people could continue using their pre-OS X apps. It took six years before enough developers had upgraded that Apple could stop supporting Classic. And Classic, of course, was all about HFS+. So Apple could either backport this hypothetical unix-style filesystem to OS 9, do something kludgerous with single-machine file-sharing, require all users to partition their drives and keep everything they wanted to use in Classic on the HFS+ partition (a tough sell!), or just use HFS+ and get on with it. They wanted to stay afloat, so they stuck with HFS+, and here we are today.

[josh64]

You used to be able to install Mac OS X on UFS volumes but unfortunately they removed that option in later releases :(