[mdip]

So, based on reading the comments (and I tend to agree), the issue isn't that HFS+ is bad because it supports Resource Forks, many file systems support similar concepts.

The question becomes why is OSX storing font data in the Resource Fork rather than what everything else understands is the actual content of the file itself? On other file systems that I'm familiar with, alternate streams are for storing metadata. There's important information there, for sure, but I'm not aware of other cases where the metadata stream stores the data in absence of the data being present in the part of the file that everything understands is the file's data. In this case, it appears OSX stores the font in this alternate stream. This seems like an error in design when coupled with the fact that other, normal applications, can't understand the file in a way that makes doing normal file operations on it possible (attaching it to an e-mail or sending it via Skype).

I'm sure there's a reason the content is stored there that my lack of OSX experience would explain. The part I have a problem with is that reading that file provides an inconsistent experience within the operating system. Finder can see the file. 'cp' not only sees the file, but when copying it, renders a copy with the contents in the data, not resource fork[1]. It smells like an API problem; the wrong method is being used to read the file by these other programs (like grabbing a pointer to a symbolic link instead of grabbing what it points to), but I don't write software for OSX, so does anyone know the specifics of why this design was chosen for fonts and other resources vs. storing the data in the actual part of the file that other programs would expect to to reside?

[1] I'm basing this statement only on the author's description of what happened. I do not own a Mac, myself.

[Someone]

Mac OS was severely resource constrained. Applications typically had less memory to run in than the screen and audio buffers together used (32 kB)

Also, the CPU Mac OS ran on did not support virtual memory.

To make such a system run, applications were split into several code segments. For example, no sane program would load its printing code into memory before the user actually tried to print, and individual MacPaint commands might be located in independently loaded pieces of code, too. Resource forks and their standardized format allowed that.

Once that code was in place, using it for all kinds of other data that wasn't always needed such as fonts, drivers, or desk accessories became the logical thing to do.

It just was easier, and put less of a constraint on memory to access a font as a set of resources than to write a similar, but separate piece of code for handling the reading of fonts from regular files.

See http://www.folklore.org/StoryView.py?project=Macintosh&story... for a description by someone who worked on this.

For me, the only weird thing is that they chose to use alternate forks. They could just as well have stored the resource fork data in the only data stream in a file. My guess would be that they did that so that they had the freedom to also write portable file formats to files that also contained resources (it certainly wasn't so that they could write secret messages in the System file. That happened way later, with system 7)