So, based on reading the comments (and I tend to agree), the issue isn&#x27;t that HFS+ is <i>bad</i> because it supports Resource Forks, many file systems support similar concepts.<p>The question becomes <i>why is OSX storing font data in the Resource Fork rather than what everything else understands is the actual content of the file itself</i>?  On other file systems that I&#x27;m familiar with, alternate streams are for storing metadata.  There&#x27;s important information there, for sure, but I&#x27;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 <i>the file&#x27;s data</i>.  In this case, it appears OSX stores <i>the font</i> in this alternate stream.  This seems like an error in design when coupled with the fact that other, normal applications, can&#x27;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).<p>I&#x27;m sure there&#x27;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.  &#x27;cp&#x27; 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&#x27;t write software for OSX, so does anyone know the specifics of <i>why</i> 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?<p>[1] I&#x27;m basing this statement only on the author&#x27;s description of what happened. I do not own a Mac, myself.