
HFS+ is crazy - jodyribton
http://liminality.xyz/hfs-is-crazy/
======
rogerbinns
Alternate parts to the main file are present on several platforms, and have
the same problems. They are called resource forks on Mac.

On Windows/NTFS they are called alternate data streams -
[https://en.wikipedia.org/wiki/Fork_(file_system)](https://en.wikipedia.org/wiki/Fork_\(file_system\))
\- to use specify a colon and name after the filename (eg example.txt:myads).

On Unix, Linux, OS/2 etc you can find extended attributes -
[https://en.wikipedia.org/wiki/Extended_file_attributes](https://en.wikipedia.org/wiki/Extended_file_attributes)
\- which allow storing key value pairs on a file. Restrictions exist and vary.

As for an example of them being helpful - on Windows when you download a file
from the Internet using a browser an extended attribute is used to mark that.
Trying to execute the file from Explorer then explains that it was downloaded
and asks if you really want to proceed.

On Linux selinux can store labels in the extended attributes.

Older ignorant tools aren't going to know about this, but don't substantially
harm anything. Modern tools do know about them and do the right thing. (eg
copying a downloaded file elsewhere on Windows will still give the warning).
The Linux GNU cp command does require a --preserve xattr flag to copy extended
attributes and does not do so by default. Dropbox does support them by default
and cross platform.

~~~
stefantalpalaru
You wouldn't put the entire content of a file in an extended attribute, would
you?

~~~
blakeyrat
On Mac Classic, if you wanted to ship a custom font with your application,
you'd put it in the Resource fork in a resource of "FONT" type.

So why wouldn't a stand-alone font file consist of a Resource fork with a
single resource of "FONT" type? Otherwise, the OS engineers have to develop
two entirely different ways of reading in font data. Why duplicate the effort?

The system made perfect sense, both then and now. It bothers me that so few
people know anything about Mac Classic, it really was an amazingly well-
designed OS for its time.

~~~
mbell
> an amazingly well-designed OS for its time

It had a few interesting ideas. But no desktop OS based on cooperative
multitasking can be called 'well-designed', almost anything could hard-lock
the entire system at any time.

~~~
icedchai
AmigaOS was a lot better designed and had full preemptive multitasking, etc.
Too bad Commodore sucked at marketing.

------
thought_alarm
It's amazing how garbage like this always rockets to the top of HN. This guy
doesn't know anything about file systems or about the operating system he's
using. But he sounds confident, so that's evidently good enough for a lot of
people.

If you think it's crazy that a file system supports multiple data
forks/steams, then you don't know very much about file systems.

If you think it's crazy that an operating system maintains backward
compatibility with an older system, then you don't know very much about
operating systems.

If you arrogantly make these pronouncements on your website then you look like
a complete idiot.

~~~
Profan
People don't know what they don't know. Talking down to people who think
something is strange for being the way it is, instead of explaining to them
why it is, is so counterproductive and serves no purpose. Everyone has things
they don't know, just provide an explanation instead of an arrogant comment.

He even says "I'm sure there's an Apple-y reason for the existence of this
feature, but I can't imagine what it might be." That's literally a "i'm not
sure why this is" right there!

~~~
saidajigumi
This _isn 't_ about what the author does/doesn't know. The author managed to
figure out that this was about resource forks, meaning that clearly they'd
done some footwork and had found the right thread of information to follow.

But GP's point gets to how the author handled that new knowledge: post an
essay of cranky, self-assured tone to their website instead of following that
thread to understand how and why OS X resource forks came to be. I.e. they
followed the path of "anything I don't already know must be wrong":

 _I 'm sure there's an Apple-y reason for the existence of this feature, but I
can't imagine what it might be._

It's hard not to bash this kind of rhetorical mess. "I took the time to
research everything up to here, then _EPIC FLOUNCE!_ "

If you're going to write an article critical of HFS+, perhaps making an
argument for a successor, _great!_ It's a topic I'll get wholeheartedly
behind. But this article is just lazy bitching on the internet, which
certainly doesn't deserve to be voted up.

~~~
btilly
Well, both points of view have a point.

The central idea of Unix is that everything is a file. Files are just streams
of bytes on disk. Most happen to be text. Text is just streams of lines. And
then you write a bunch of simple tools that handle files, bytes, and lines,
and they will combine really well for more complex tasks.

However this was (and in many corners still is) a radical idea. The natural
tendency in virtually every other system, from the Macintosh to IBM
mainframes, was to store data in various structured records. Whether we're
talking resource forks or records, you always, always, always add structure of
various kinds. The idea of just scanning through bytes to find, say, the end
of a record is shockingly inefficient.

So we have the point of the article. HFS+ breaks Unix. If you don't see that,
then you don't actually understand Unix. The filesystem ignores one of the
founding central concepts, with the result that the entire Unix toolkit and
way of thinking about the world doesn't work. Standard utilities, scripts, etc
don't know that resource forks exist, and will do the wrong thing with them.
If you walk into OS X and are told, "It's Unix under the hood", well that is a
lie. It really isn't. You can work within it and only do Unix things and it
will work, but as soon as you access things from elsewhere in the Apple
ecosystem, things break in ways that they wouldn't in, say, Linux.

But we also have your point of view. There are very good reasons that HFS+
works the way it does. And it is integrated into the UI in ways that date back
decades. And THIS is true. OS X was an attempt to put a Macintosh UI on a fork
of Unix. And preserving central concepts of Unix really were not as important
as making the UI work right. With the same features. With data being
reasonably easy to port between the two systems, and programs not
unnecessarily different.

Both points of view are valid. Which one matters depends on what you're trying
to do. Furthermore it is natural, not stupid, that a person who has just had a
major plank pulled out from under their way of understanding the world tends
to have a strong emotional response.

"OMG, you broke everything! The tools that I rely on don't work and I have no
idea what else is broken!" This is an extremely common response. This is one
of the reasons why it can be hard for programmers to switch languages and
environments.

As it happens, I personally understand both points of view. I have over 20
years of experience with both Macs and Unix. This is typed on an Apple laptop.
But fundamentally I agree with the article. Apple broke Unix. I recognize that
there is no solution at this point, and I mostly confine myself to living
within the Unixy parts of the system. But HFS+ got it wrong and is not well
integrated with the command line. I mean look at this. If you have myfile you
can look at myfile. Then ls myfile/..namedfork and get an error. Then ls
$file/..namedfork/rsrc and see more stuff??? And I can only know to do this if
I know it is there to be seen???

That's just broken.

~~~
JupiterMoon
I was under the understanding that Apple never originally really intended
people to use the Unix side of OSX and that the whole command line standard
Unix utilities became commonly used in spite of Apple's design. I could be
wrong.

~~~
btilly
I have no idea if there was a conscious choice either way. However the goal
was certainly, "Our cooperative multi-tasking system where any bad application
takes out the operating system no longer cuts it, migrate to a preemptive
one." And building on Unix was the shortest path there.

There were many disconnects between the two systems. See
[https://www.usenix.org/legacy/event/usenix2000/invitedtalks/...](https://www.usenix.org/legacy/event/usenix2000/invitedtalks/sanchez_html/)
for some of them.

------
coldtea
> _Applications — even basic filesystem tools — aren 't aware of the
> additional content. How do you deal with a file with two sets of data? I'm
> sure there's an Apple-y reason for the existence of this feature, but I
> can't imagine what it might be._

G.K. Chesterton on the matter:

In the matter of reforming things, as distinct from deforming them, there is
one plain and simple principle; a principle which will probably be called a
paradox. There exists in such a case a certain institution or law; let us say,
for the sake of simplicity, a fence or gate erected across a road. The more
modern type of reformer goes gaily up to it and says, “I don’t see the use of
this; let us clear it away.” To which the more intelligent type of reformer
will do well to answer: “If you don’t see the use of it, I certainly won’t let
you clear it away. Go away and think. Then, when you can come back and tell me
that you do see the use of it, I may allow you to destroy it.”

This paradox rests on the most elementary common sense. The gate or fence did
not grow there. It was not set up by somnambulists who built it in their
sleep. It is highly improbable that it was put there by escaped lunatics who
were for some reason loose in the street. Some person had some reason for
thinking it would be a good thing for somebody. And until we know what the
reason was, we really cannot judge whether the reason was reasonable. It is
extremely probable that we have overlooked some whole aspect of the question,
if something set up by human beings like ourselves seems to be entirely
meaningless and mysterious. There are reformers who get over this difficulty
by assuming that all their fathers were fools; but if that be so, we can only
say that folly appears to be a hereditary disease.

~~~
rch
I prefer the less verbose version:

"Don't just do something. Stand there."

\--Marvin Minsky

~~~
jarcane
[http://quoteinvestigator.com/2014/03/22/stand-
there/](http://quoteinvestigator.com/2014/03/22/stand-there/)

~~~
rch
Thanks! I've wondered about that from time to time.

Here's a link to Minsky's Law (actually two):

[https://edge.org/response-detail/11644](https://edge.org/response-
detail/11644)

If I recall correctly, it's also mentioned in The Society of Mind.

------
mwfunk
This would have been a lot more compelling if it basically wasn't just
somebody stating the existence of resource forks and acting like that's a
surprise. If someone knows just one thing about HFS+, it's that it's kludgey
wrapper around the ancient Mac OS filesystem which added POSIX behaviors and
other more modern niceties that no one at Apple was thinking about in the
'80s. If someone knows just two things about HFS+, the second thing is the
existence of resource forks.

There are wide, deep, rich, fertile fields of HFS+ criticism to be had- low
hanging fruit just dripping with potential for hundreds if not thousands of
snarky blog entries about problems with HFS+ for people to post to HN. This is
not one of them. The filesystem situation on OS X has such a long, tortured,
and widely documented history of technical and human failure that even the
Cleveland Browns should feel sorry for it.

There is at least one extremely old, legacy font file format supported by OS X
in which the entire font is in the resource fork. Other than that, resource
forks themselves have been deprecated for the entire existence of OS X. This
is like stumbling across some ancient vestige of DOS compatibility in Windows
and treating that discovery like a smoking gun gotcha moment that you're
certain is going to blow everyone's minds.

------
Analemma_
HFS+ isn't so much "crazy" as it is "really friggin old". It's not much more
than a coat of paint on top of HFS, which was introduced in 1985 (!), and thus
is missing out on the last three decades of filesystem research.

I might be too optimistic, but I've been assuming that Apple started
development on a replacement for HFS+ as soon as the ZFS deal collapsed. I
know that was years ago, but filsystems take a looooong time to get right.
It's coming, guys, I promise!

~~~
lukifer
My hunch is that they've got something brewing that is optimized for a post-
SATA, SSD-only world, and they won't release it until that describes most/all
of their product line.

~~~
mappu
F2FS or YAFFS2 would be cool replacements.

------
kennu
TLDR: Mac filesystems have resource forks. I guess the author has not used
Macs too much, as they have been around since the 1980's.

~~~
idbentley
TLDR: all standard applications for working with files are unaware of resource
forks. This is confusing, and hurts new computer users. #consideredharmful

~~~
coldtea
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.

So it sure might be confusing (and I see how) but it's absolutely not very
common.

~~~
KirinDave
> 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.

~~~
coldtea
> _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?

------
pauldino
Nobody else really uses them to the extent Apple does, but this sort of thing
isn't unique to HFS+.

[https://en.wikipedia.org/wiki/Extended_file_attributes](https://en.wikipedia.org/wiki/Extended_file_attributes)

You can do the exact same thing on Windows (on an NTFS volume), just go to a
command prompt and run "notepad hello.txt:secret" and see how DIR and Windows
Explorer deal with it.

~~~
ADSstreamsthrow
"Alternate Data Streams."
[https://en.wikipedia.org/wiki/Fork_%28file_system%29#Microso...](https://en.wikipedia.org/wiki/Fork_%28file_system%29#Microsoft)

------
zeveb
Resource forks were pretty cool, actually: they were a simple database
attached to every file, which could be used to store metadata or other
information. It was pretty common for applications to store fonts, icons &c.
all in their resource forks.

Back when I was a kid I used to use ResEdit to change application & file
icons, fiddle with GUI controls, change menu structures and so on. Happy days!

~~~
btown
I remember back in the day I would hack on mods for a series of games called
Escape Velocity. And these mods were entirely created using resource forks for
everything from game logic to flavor text to images. ResEdit was the closest
thing we had to an IDE. Compared to source control that would allow us to
collaborate, or even SQlite databases that could be trivially backed up, it
felt like we could lose our work at any time. But at the end of the day, that
was part of the fun.

More info on how it worked: [https://en.wikipedia.org/wiki/Plug-
in_(Escape_Velocity)](https://en.wikipedia.org/wiki/Plug-
in_\(Escape_Velocity\)) (why this is a relevant article in Wikipedia, I have
no idea.)

Note to anyone reading this, though: If you're designing a system from
scratch, don't even think about using resource forks to store data. Just say
no.

------
jcsiracusa
If you'd like to learn more about resource forks on the Mac, which were a very
clever solution to a difficult set of problems, please read this, written by
the person who created them:

[http://www.folklore.org/StoryView.py?story=The_Grand_Unified...](http://www.folklore.org/StoryView.py?story=The_Grand_Unified_Model.txt)

If you want to know more about the invention and early history of the
Macintosh in general, there's tons more at
[http://www.folklore.org](http://www.folklore.org) (or in the book based on
it, Revolution in The Valley, by Andy Hertzfeld).

------
gnu8
This is why it was really disappointing that Apple had to abandon ZFS. ZFS is
one of the best file systems available and because Oracle owns it it is
virtually unusable in most contexts.

I wonder if Apple can afford to buy out Oracle at this point, take ZFS and
wind up the useless parts.

~~~
cowsandmilk
Apple abandoned ZFS when Steve Jobs was still alive. Larry Ellison has
frequently described Steve Jobs as one of his best friends whom he frequently
went on walks with. The idea that Steve could not have gotten Larry to license
ZFS seems crazy to me.

~~~
umanwizard
Did Jobs really know/care about technical details like what filesystem OS X
used?

~~~
eli
At one point it was a significant bullet point in the list of features being
added to OS X Server. It was a big deal. I'm sure he was aware of it.

[http://www.zdnet.com/article/apple-announces-zfs-on-snow-
leo...](http://www.zdnet.com/article/apple-announces-zfs-on-snow-leopard/)

~~~
dlitz
I used OS X Server in 2008. It had major quality issues that seemed to only
get worse with subsequent releases. Several advertised features accessible
from the UI didn't work or straight-up broke things. I doubt Jobs paid much
attention to it.

------
barkingcat
Resource forks aren't anything new - it's existed since the dawn of macs - if
you haven't known about resource forks while working with macs maybe you
should learn a bit more about the core of the platform.

That said, I agree, it's a horrible design - but it's existed for 20+ years
already.

For me, this is just like saying "hey people! FAT is horrible, it only allows
8 character + 3 character extension file names!"

~~~
coldtea
> _That said, I agree, it 's a horrible design - but it's existed for 20+
> years already._

Actually there's absolutely nothing horrible about resource forks/extended
attributes in theory.

We use way worse ideas like "sidecar" files and metadata stored centrally for
the same use cases, which are worse ways to handle the issue.

The real problem is the lack of agreement/interoperability in handling them
across FSs (and perhaps tooling).

~~~
blakeyrat
The problem is that *nix tools only support technology that existed in 1972.
Anything newer than that is screwed.

Mac Classic's death knell was the increasing popularity of the Internet. Run
by servers that couldn't possibly store Mac Classic files correctly, because
guess what? Resource forks/alternative data streams/whatever didn't exist back
in 1972.

And yes I am still bitter about this.

~~~
coldtea
That's an important point. I think however elegant for its time the 70s/early
80s UNIX design, it holds us back in many ways.

It's amazing that we still widely use a language without a string type and
memory safety like C for example, instead of something like Rust, Swift and co
-- with occasional excursions to unsafety maybe for speed/interoperability
with older libs, but not as the default for the whole goddamn codebase. And
don't get me started in stdlib and co.

Other stuff too. A common "file resources" standard. X11. All the way to
Makefiles and permissions (with stuff bolted on, like ACL). Oh, and the
horrible conventions of file paths (dumping everything in /usr/bin and co,
splitting an installed app into 5+ different directories for man files,
resources, etc).

It's amazing how even a simple improvement like systemd gets tons of
negativity from admin types and people who think 70s designs should be set in
stone.

~~~
digi_owl
> It's amazing how even a simple improvement like systemd gets tons of
> negativity from admin types and people who think 70s designs should be set
> in stone.

That is misrepresenting (perhaps to the point of straw man) the systemd
complaints.

~~~
coldtea
> _That is misrepresenting (perhaps to the point of straw man) the systemd
> complaints._

Maybe, but not the one's I've seen. Can you point to some collection of
systemd complaints that go beyond "this is not how things used to be done"?

~~~
digi_owl
[http://without-
systemd.org/wiki/index.php/Arguments_against_...](http://without-
systemd.org/wiki/index.php/Arguments_against_systemd)

~~~
coldtea
Most of these are either of the "it's not how it used to be done variety", bug
complaints (which can and do get fixed), and "straying of the unix way" (as if
that is a technical argument.

Sometimes you DO need to stray off the UNIX way to improve things, namely any
time "does one thing well" comes to the detriment of "needs overall overview
and cooperation instead of a disparate set of things that can't be glued
properly for the task based on a motto meant for simple text-based
input/output programs".

There are some valid concerns too, but nothing that's a show-stopper -- which
also explains why the show didn't stop.

~~~
digi_owl
OVerview and cooperation, sure. But everything in one ball of code because of
"APIs"?!

------
justizin
I'm sorry, OP, but NTFS has resource forks as well, and they have value. The
fonts are probably in resource forks because you are prohibited by copyright
from copying or transferring them, but in other situations, they represent
data that is only valuable to Mac OS, so that, say, if you rsync a bunch of
files to a UNIX/Linux machine, you don't get things that are OSX-specific.

That said, it is a fairly non-transparent and mysterious bit of functionality.

My favorite thing about HFS+ is that about ten years ago at WWDC, I sat in
with the Darwin Filesystem Birds-of-Feather, and asked them why it is case
sensitive. They gave me a very simple answer:

    
    
      Microsoft Office.
    

Office, like basically apparently all Microsoft software, aggressively takes
any filename string you give it and sends it through a rube-goldberg machine
of forced uppercasing and lowercasing at several levels of the application,
and therefore does not reliably open "Something.txt" as "something.txt" or
"SOMETHING.TXT", but will absolutely never open "Something.txt".

So, on my personal Macs, I actually run HFS+X, which is case sensitive and was
designed for OSX Server. Homebrew works, all Apple apps and native Mac apps
work. Office will almost definitely still not, but LibreOffice will.

~~~
Flow
FYI - Steam requires a case-insensitive filesystem. :-(

[https://support.steampowered.com/kb_article.php?ref=8601-RYP...](https://support.steampowered.com/kb_article.php?ref=8601-RYPX-5789)

~~~
bluedino
So do Adobe products.

[https://helpx.adobe.com/creative-suite/kb/error-case-
sensiti...](https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-
drives-supported.html)

------
rbanffy
Ignorance of the past may lead one to incorrect conclusions.

Resource forks were a clever way to keep things like icons, fonts, text
messages and dialog box definitions bundled within a single program file
(remember - on Macs the install/uninstall procedure is usually dragging an
icon).

Many times I've customized programs this way.

HFS+_is brain-dead for a multitude of reasons. This is not one of them.

------
glhaynes
_" I'm sure there's an Apple-y reason for the existence of this feature, but I
can't imagine what it might be."_

I know this feeling well but I don't really get how it causes some people to
think "I'll write a blog post complaining about this" rather than "I'll do a
quick search for this and find out the answer, which might be nuanced,
historically contingent, and/or revelatory."

------
oofabz
I'd like to see Apple adopt the HAMMER2 filesystem from DragonflyBSD. It's a
very full-featured filesystem, with snapshots, file history, and hashes for
integrity checking. Snapshots could integrate with Time Machine, and file
history with Apple's file versions feature.

It doesn't have as many features as ZFS or Btrfs, but it's much better than
HFS+. Plus it's BSD-licensed and unencumbered by patents, so Apple could do
whatever they want with it.

~~~
krylon
That would be sweet, indeed. How far along is HAMMER2 these days?

~~~
ADSstreamsthrow
Not far enough for Dragonfly to use it. There's a greater chance of Apple
adopting BTRFS (i.e., not a snowball's chance in hell).

~~~
oofabz
If they need something in the short term they could use HAMMER 1, it's been
stable for years.

------
larvaetron
> I'm sure there's an Apple-y reason for the existence of this feature, but I
> can't _be bothered to read the Wikipedia article that I linked to in my cuh-
> ray-zee blog post._

------
aroch
Isn't the point of resource forks to store structured data; like a font
bitmap? The pictured font looks like a third party font, suggesting whoever
exported it for release chose to export in such a way that data was only
stored in the resource fork, perhaps as a lazy-man's DRM

~~~
JonathonW
It's a font in the old Suitcase format from classic Mac OS-- it's not a lazy-
man's DRM; it was the way fonts were supposed to be stored. Fonts were
resources, so their data went into the file's resource fork.

------
mehrdada
HFS+ is a crap filesystem for many reasons. Resource fork is not one of them.

------
to3m
Interesting that it is HFS+ getting accused of being crazy, rather than the
(blatantly deficient) POSIX-style tools!

~~~
gherkin0
> Interesting that it is HFS+ getting accused of being crazy, rather than the
> (blatantly deficient) POSIX-style tools!

That's UNIX parochialism for you.

~~~
GFK_of_xmaspast
I guess there really are more things under heaven and earth than dreamt of in
the unix philosophy.

------
csydas
This is likely just my ignorance speaking in regards to the deeper workings of
filesystems, but having used OS 7-9 and OS X since release, the issue brought
up in the article has never been an issue for myself, my colleagues and
friends as we sent data back and forth, or even something I was aware of as I
used various Macs.

Is there a specific reason that this becomes problematic to even most power
users outside of specific files being read differently by older tools? Reading
the Linus rant on HFS+ I can understand to some degree and appreciate where
this becomes a problem, but it just seems like the author found a small
outlier issue with how an old font was handled with HFS(+) and condemned the
entire system.

------
tshtf
Another fun issue in OS X HFS+ happens due to unicode normalization; any
filename containing an ignorable unicode character is first normalized:

cat /etc/passwd`python -c 'print "\xe2\x80\x8c"'`

This led to a security issue with Git ([http://git-
blame.blogspot.com/2014/12/git-1856-195-205-214-a...](http://git-
blame.blogspot.com/2014/12/git-1856-195-205-214-and-221-and.html)) and one in
Apache a few years earlier.

------
mpweiher
>Applications — even basic filesystem tools — aren't aware of the additional
content.

That's not actually true. Most if not all Unix utilities have been updated to
deal with resource forks, and they have been integrated into the Unix
directory hierarchy by treating the actual file as a single level directory.

The fact that the resource fork is invisible by default is the most reasonable
way I can think of. Other options such as concatenating all the forks together
or treating the file itself as a single level directory by default _would_
actually break everything.

The solution that they found is to have this interpretation (the file is
really a single-level directory) accessible, but make one fork (the data fork)
the default "bag of bytes" for most of the Unix tools.

For example:

    
    
       file  /tmp/Euclid/..namedfork/rsrc
       /tmp/Euclid/..namedfork/rsrc: MS Windows icon resource
    

Well, wrong answer, but correct access to the file.

That was a copy of a resource-fork based font I created by typing:

    
    
        cp Euclid /tmp/
    

The `cp` command copied the resource fork just fine. tar was also updated to
handle resource forks and other metadata. I know this because long ago I
created `hfstar`[1] to do just that, because the tar that came with the OS
hadn't been updated yet. Today, hfstar is no longer necessary.

[1]
[http://www.macupdate.com/app/mac/9405/hfstar](http://www.macupdate.com/app/mac/9405/hfstar)

------
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...](http://www.folklore.org/StoryView.py?project=Macintosh&story=Font_Manager.txt)
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)

------
thoughtsimple
The file is compressed.

Info here: [http://unix.stackexchange.com/questions/96491/why-does-du-
re...](http://unix.stackexchange.com/questions/96491/why-does-du-report-a-
size-of-0-for-some-non-empty-files-on-a-hfs-partition)

The last answer (marked for 0 points of course) is probably correct in this
case. The file fits in the extended attributes.

------
imglorp
Not to mention case insensitivity... Ugh!

~~~
amock
HFS+ can be case sensitive, it's just that many Mac applications will not work
if it is.

------
niccaluim
Wow, a font suitcase? Use a font format from the '80s and you deserve
everything you get I guess ;)

------
iSnow
The kids today - know nothing about resource forks. Probably have never seen
ResEdit either.

How do you even build applications?

------
trollian
I miss ResEdit...

------
Skunkleton
Wouldn't it be cool if Apple just picked up a standard file system from
somewhere else? Ext4 for example.

~~~
coldtea
They would still keep something like resource forks. Most modern filesystems
have them. Here's the man page for Ext4 and co on them:

[http://manpages.ubuntu.com/manpages/precise/man5/attr.5.html](http://manpages.ubuntu.com/manpages/precise/man5/attr.5.html)

~~~
duskwuff
Heck - at this point, resource forks are exposed as a "com.apple.ResourceFork"
xattr with a large binary value. The primary remaining visible quirk is that
they're also accessible via a magic path ("file/..namedFork/rsrc") -- the fact
that the file system has a special way of storing them is irrelevent to
userspace.

~~~
yrro
Ah, that explains why people in this thread are so confused between alternate
forks/streams, and extended attributes!

------
sabujp
HFS+ is "modern".

------
jbverschoor
OH I miss the BFS

~~~
shawn-butler
I think its "mostly" implemented in Syllable. Not sure what Haiku did.

