14 ms·

HFS+ is crazy

192 points by jodyribton 11y ago

kennu 11y ago
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.
- vezzy-fnord 11y ago
  The utility of such a feature relative to its security, integrity and astonishment costs can be debated, however. ADS in NTFS has long been a subject of pain, for instance, though I'm unaware of its present status.
  - gnu8 11y ago
    I think it is chiefly used by malware developers at this time.
    - ADSstreamsthrow 11y ago
      It's used widely by popular applications (Adobe / Microsoft software products).
      - mst 11y ago
        Which are, in my experience, more ransomware than malware.
    - makomk 11y ago
      To be fair, it's also used by DRM schemes and those aren't technically malware as such.
  - kennu 11y ago
    I agree that they could probably be deprecated and removed nowadays. There used to be a transition time when people ran old Mac OS applications on OS X.
- idbentley 11y ago
  TLDR: all standard applications for working with files are unaware of resource forks. This is confusing, and hurts new computer users. #consideredharmful
  - coldtea 11y ago
    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 11y ago
      > 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 11y ago
        >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?
- joezydeco 11y ago
  Maybe a lot of us (as I did, to be honest) thought that Mac resources went away with the advent of NextStep/OSX.
  - msbarnett 11y ago
    That would have completely destroyed backwards compatibility for a large number of Mac OS users' files. Remember that you could run Mac OS Classic apps on the first few iterations of OS X, and even after you couldn't any more, Carbonized/Cocoized OS X Apps still could open old files you created, many of which heavily used resource forks.
    - duskwuff 11y ago
      AND many Carbon apps, even ones which wouldn't run on Classic Mac OS, would still load resources from a resource fork.
gnu8 11y ago
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 11y ago
  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 11y ago
    Did Jobs really know/care about technical details like what filesystem OS X used?
    - eli 11y ago
      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-leopard/ http://www.zdnet.com/article/apple-announces-zfs-on-snow-leo...
      - dlitz 11y ago
        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.
    - rdancer 11y ago
      Why would you think he wasn't? Many anecdotes mention him micromanaging minute details, and many of the things he mentions in keynotes are highly technical as well as low-level.
aroch 11y ago
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 11y ago
  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.
pauldino 11y ago
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 11y ago
  "Alternate Data Streams." https://en.wikipedia.org/wiki/Fork_%28file_system%29#Microsoft https://en.wikipedia.org/wiki/Fork_%28file_system%29#Microso...
oofabz 11y ago
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 11y ago
  That would be sweet, indeed. How far along is HAMMER2 these days?
  - ADSstreamsthrow 11y ago
    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 11y ago
      If they need something in the short term they could use HAMMER 1, it's been stable for years.
barkingcat 11y ago
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 11y ago
  >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 11y ago
    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 11y ago
      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.
Analemma_ 11y ago
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!
- oblio 11y ago
  I hope you're not right. There are so many wonderful filesystems already out there, many of them already Open Source. I'm not against research, but I'd rather have Apple fund one of these existing efforts.
  - bydo 11y ago
    Which? Apple won't adopt anything GPL, so BTRFS, XFS, JFS, etc--basically every Linux project is right out. It was almost ZFS, years ago, but Apple backed out when Oracle bought Sun. What out there is modern, good, and under a compatible license? HAMMER?
    - deftnerd 11y ago
      They could probably buy up the rights to BeFS for really cheap now. It was a beautiful file system, in my opinion.
      - chipotle_coyote 11y ago
        IIRC, they hired Dominic Giampaolo to work on the file system for a while -- he was responsible for adding journaling to HFS+ and started Spotlight, which has a lot in common with BeFS's attributes. He apparently worked on a new file system for them but it never shipped. http://www.nobius.org/~dbg/ http://www.nobius.org/~dbg/
    - jedisct1 11y ago
rogerbinns 11y ago
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.
- deleted 11y ago
  [deleted]
  - cstross 11y ago
    Actually, resource forks go all the way back to the origins of classic MacOS circa 1984-85! And they were a lot more than just extended attributes -- they were a b-tree storage abstraction full of stuff like icons, chunks of 68K machine code, and anything else that simply didn't belong in a linear data file. It's a hold-over from MacOS's very non-UNIX origins, and had the makings of an OO filesystem back in the day -- but then the adoption of NeXTStep -- er, sorry, OSX -- obsoleted it overnight. And now it's basically the veriform appendix of OSX, and leads newbies to jump to this rather odd conclusion (that it's somehow "crazy" to do something in a fundmentally non-UNIXy way).
    - sanderjd 11y ago
to3m 11y ago
Interesting that it is HFS+ getting accused of being crazy, rather than the (blatantly deficient) POSIX-style tools!
- gherkin0 11y ago
  > 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 11y ago
    I guess there really are more things under heaven and earth than dreamt of in the unix philosophy.
coldtea 11y ago
>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 11y ago
  I prefer the less verbose version: "Don't just do something. Stand there." --Marvin Minsky
  - coldtea 11y ago
    Damn, I knew this quote for 2+ decades, and I thought it was just a funny wordplay, reversing the usual wording. Only now with your comment it occurred to me it has the same sense with the Chesterton quote, that it's against "just doing something" mindlessly!
  - jarcane 11y ago
Skunkleton 11y ago
Wouldn't it be cool if Apple just picked up a standard file system from somewhere else? Ext4 for example.
- coldtea 11y ago
  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 11y ago
    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 11y ago
      Ah, that explains why people in this thread are so confused between alternate forks/streams, and extended attributes!
- mirekrusin 11y ago
  ext4 deprecation hangs in the air and it's not very good filesystem, btrfs is probably the future and it's slowly becoming production ready.
  - justizin 11y ago
    yah absolutely ext4 has progressively had its' performance reduced because what made it faster than ext3 created a lot of corner cases that make it far less reliable, and Btrfs is at least a fresh design, but doesn't seem to be particularly ready and is not even proven as a reliable design. It's good that we have more than one filesystem. HFS+ functionally works well for a Mac because the Mac is designed around it, but it is part of the reason that OSX falls short as a UNIX at times.
imglorp 11y ago
Not to mention case insensitivity... Ugh!
- amock 11y ago
  HFS+ can be case sensitive, it's just that many Mac applications will not work if it is.
imglorp 11y ago
Not to mention case insensitivity... Ugh!
csydas 11y ago
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.
zeveb 11y ago
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!
- azinman2 11y ago
  Me too. ResEdit was magic to a 10 year old (myself). The author clearly has no idea what he's talking about, except pointing out long known issues in transferring files with resource forks to other operating systems.
- btown 11y ago
  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.
- wsc981 11y ago
  I used to edit levels with ResEdit for the Mac Bomberman clone BOOM. Good times :)
- __david__ 11y ago
  Yes, this is what most of the other comments aren't emphasizing—resource forks had a standardized format and Apple even shipped a tool for visualizing/editing them. They were also extended so you could tag and embed any arbitrary data you wanted to. This was fantastic because it allowed me as a young programmer to poke around in real shipping products and see how they organized things. The same way you might poke around inside an .app wrapper or a .xib file nowadays. But 30 years ago! From today's perspective, they are just there for backwards compatibility.
yanazendo 11y ago
xyz lulz
- hundchenkatze 11y ago
  Why is this funny?
  - yanazendo 11y ago
    Proof of work steganography
thoughtsimple 11y ago
The file is compressed. Info here: http://unix.stackexchange.com/questions/96491/why-does-du-report-a-size-of-0-for-some-non-empty-files-on-a-hfs-partition http://unix.stackexchange.com/questions/96491/why-does-du-re... The last answer (marked for 0 points of course) is probably correct in this case. The file fits in the extended attributes.
thought_alarm 11y ago
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.
- andrewmcwatters 11y ago
  I'm tired of having discussions with people on HN for this very reason. It's such a joke.
  - dang 11y ago
    Please stop posting comments that lower the quality of the site even further. Instead, post nothing or find a way to improve the discussion. Quite a few users have done so in this very thread, so you needn't look far for inspiration.
- Profan 11y ago
  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!
  - andrewmcwatters 11y ago
    Searching for meaning rather than judging something over face value is a sign of an educated person. You would expect more of those types on HN, but instead there's seemingly a crowd of predominantly hyperopinionated tinkerer-types.
rbanffy 11y ago
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.
tshtf 11y ago
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-and-221-and.html http://git-blame.blogspot.com/2014/12/git-1856-195-205-214-a...) and one in Apache a few years earlier.
larvaetron 11y ago
> 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.
jbverschoor 11y ago
OH I miss the BFS
- shawn-butler 11y ago
  I think its "mostly" implemented in Syllable. Not sure what Haiku did.
mwfunk 11y ago
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.
justizin 11y ago
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 11y ago
  FYI - Steam requires a case-insensitive filesystem. :-( https://support.steampowered.com/kb_article.php?ref=8601-RYPX-5789 https://support.steampowered.com/kb_article.php?ref=8601-RYP...
  - bluedino 11y ago
    So do Adobe products. https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html https://helpx.adobe.com/creative-suite/kb/error-case-sensiti...
- niccaluim 11y ago
  It's got nothing to do with copyright. Classic Mac OS, from which HFS+ descends, happily copied both forks of a file for you. I'd be shocked if OS X's Finder didn't also copy both forks. I believe cp also supports them. And you can access them on the command line by appending "..namedfork/rsrc" to the filename. Although resource forks were just another data stream at the filesystem level, the OS treated them as structured data, with record types and IDs. They were used to store user interface elements--icons, pictures, window definitions, dialog boxes, etc.--as well as string lists, version information, and, yes, fonts. Even the executable was stored as a resource (M68k code that is; PowerPC binary was in the data fork). Applications could define their own resource types too. As another poster points out, this scheme helped applications manage memory by only loading into RAM the resources it actually needed at any given time.
trollian 11y ago
I miss ResEdit...
mehrdada 11y ago
HFS+ is a crap filesystem for many reasons. Resource fork is not one of them.
jcsiracusa 11y ago
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_Model.txt http://www.folklore.org/StoryView.py?story=The_Grand_Unified... 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).
mdip 11y ago
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 11y ago
  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=Font_Manager.txt 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)
sabujp 11y ago
HFS+ is "modern".
glhaynes 11y ago
"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."
niccaluim 11y ago
Wow, a font suitcase? Use a font format from the '80s and you deserve everything you get I guess ;)
iSnow 11y ago
The kids today - know nothing about resource forks. Probably have never seen ResEdit either. How do you even build applications?
mpweiher 11y ago
>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

192 points by jodyribton 11y ago

kennu 11y ago

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.

vezzy-fnord 11y ago
The utility of such a feature relative to its security, integrity and astonishment costs can be debated, however. ADS in NTFS has long been a subject of pain, for instance, though I'm unaware of its present status.
- gnu8 11y ago
  I think it is chiefly used by malware developers at this time.
  - ADSstreamsthrow 11y ago
    It's used widely by popular applications (Adobe / Microsoft software products).
    - mst 11y ago
      Which are, in my experience, more ransomware than malware.
  - makomk 11y ago
    To be fair, it's also used by DRM schemes and those aren't technically malware as such.
- kennu 11y ago
  I agree that they could probably be deprecated and removed nowadays. There used to be a transition time when people ran old Mac OS applications on OS X.
idbentley 11y ago
TLDR: all standard applications for working with files are unaware of resource forks. This is confusing, and hurts new computer users. #consideredharmful
- coldtea 11y ago
  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 11y ago
    > 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 11y ago
      >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?
joezydeco 11y ago
Maybe a lot of us (as I did, to be honest) thought that Mac resources went away with the advent of NextStep/OSX.
- msbarnett 11y ago
  That would have completely destroyed backwards compatibility for a large number of Mac OS users' files. Remember that you could run Mac OS Classic apps on the first few iterations of OS X, and even after you couldn't any more, Carbonized/Cocoized OS X Apps still could open old files you created, many of which heavily used resource forks.
  - duskwuff 11y ago
    AND many Carbon apps, even ones which wouldn't run on Classic Mac OS, would still load resources from a resource fork.

gnu8 11y ago

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 11y ago
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 11y ago
  Did Jobs really know/care about technical details like what filesystem OS X used?
  - eli 11y ago
    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-leopard/ http://www.zdnet.com/article/apple-announces-zfs-on-snow-leo...
    - dlitz 11y ago
      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.
  - rdancer 11y ago
    Why would you think he wasn't? Many anecdotes mention him micromanaging minute details, and many of the things he mentions in keynotes are highly technical as well as low-level.

aroch 11y ago

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 11y ago
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.

pauldino 11y ago

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 11y ago
"Alternate Data Streams." https://en.wikipedia.org/wiki/Fork_%28file_system%29#Microsoft https://en.wikipedia.org/wiki/Fork_%28file_system%29#Microso...

oofabz 11y ago

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 11y ago
That would be sweet, indeed. How far along is HAMMER2 these days?
- ADSstreamsthrow 11y ago
  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 11y ago
    If they need something in the short term they could use HAMMER 1, it's been stable for years.

barkingcat 11y ago

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 11y ago
>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 11y ago
  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 11y ago
    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.

Analemma_ 11y ago

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!

oblio 11y ago
I hope you're not right. There are so many wonderful filesystems already out there, many of them already Open Source. I'm not against research, but I'd rather have Apple fund one of these existing efforts.
- bydo 11y ago
  Which? Apple won't adopt anything GPL, so BTRFS, XFS, JFS, etc--basically every Linux project is right out. It was almost ZFS, years ago, but Apple backed out when Oracle bought Sun. What out there is modern, good, and under a compatible license? HAMMER?
  - deftnerd 11y ago
    They could probably buy up the rights to BeFS for really cheap now. It was a beautiful file system, in my opinion.
    - chipotle_coyote 11y ago
      IIRC, they hired Dominic Giampaolo to work on the file system for a while -- he was responsible for adding journaling to HFS+ and started Spotlight, which has a lot in common with BeFS's attributes. He apparently worked on a new file system for them but it never shipped. http://www.nobius.org/~dbg/ http://www.nobius.org/~dbg/
  - jedisct1 11y ago

rogerbinns 11y ago

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.

deleted 11y ago
[deleted]
- cstross 11y ago
  Actually, resource forks go all the way back to the origins of classic MacOS circa 1984-85! And they were a lot more than just extended attributes -- they were a b-tree storage abstraction full of stuff like icons, chunks of 68K machine code, and anything else that simply didn't belong in a linear data file. It's a hold-over from MacOS's very non-UNIX origins, and had the makings of an OO filesystem back in the day -- but then the adoption of NeXTStep -- er, sorry, OSX -- obsoleted it overnight. And now it's basically the veriform appendix of OSX, and leads newbies to jump to this rather odd conclusion (that it's somehow "crazy" to do something in a fundmentally non-UNIXy way).
  - sanderjd 11y ago

to3m 11y ago

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

gherkin0 11y ago
> 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 11y ago
  I guess there really are more things under heaven and earth than dreamt of in the unix philosophy.

coldtea 11y ago

>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 11y ago
I prefer the less verbose version: "Don't just do something. Stand there." --Marvin Minsky
- coldtea 11y ago
  Damn, I knew this quote for 2+ decades, and I thought it was just a funny wordplay, reversing the usual wording. Only now with your comment it occurred to me it has the same sense with the Chesterton quote, that it's against "just doing something" mindlessly!
- jarcane 11y ago

Skunkleton 11y ago

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

coldtea 11y ago
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 11y ago
  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 11y ago
    Ah, that explains why people in this thread are so confused between alternate forks/streams, and extended attributes!
mirekrusin 11y ago
ext4 deprecation hangs in the air and it's not very good filesystem, btrfs is probably the future and it's slowly becoming production ready.
- justizin 11y ago
  yah absolutely ext4 has progressively had its' performance reduced because what made it faster than ext3 created a lot of corner cases that make it far less reliable, and Btrfs is at least a fresh design, but doesn't seem to be particularly ready and is not even proven as a reliable design. It's good that we have more than one filesystem. HFS+ functionally works well for a Mac because the Mac is designed around it, but it is part of the reason that OSX falls short as a UNIX at times.

imglorp 11y ago

Not to mention case insensitivity... Ugh!

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

imglorp 11y ago

Not to mention case insensitivity... Ugh!

csydas 11y ago

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.

zeveb 11y ago

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!

azinman2 11y ago
Me too. ResEdit was magic to a 10 year old (myself). The author clearly has no idea what he's talking about, except pointing out long known issues in transferring files with resource forks to other operating systems.
btown 11y ago
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.
wsc981 11y ago
I used to edit levels with ResEdit for the Mac Bomberman clone BOOM. Good times :)
__david__ 11y ago
Yes, this is what most of the other comments aren't emphasizing—resource forks had a standardized format and Apple even shipped a tool for visualizing/editing them. They were also extended so you could tag and embed any arbitrary data you wanted to. This was fantastic because it allowed me as a young programmer to poke around in real shipping products and see how they organized things. The same way you might poke around inside an .app wrapper or a .xib file nowadays. But 30 years ago! From today's perspective, they are just there for backwards compatibility.

yanazendo 11y ago

xyz lulz

hundchenkatze 11y ago
Why is this funny?
- yanazendo 11y ago
  Proof of work steganography

thoughtsimple 11y ago

The file is compressed. Info here: http://unix.stackexchange.com/questions/96491/why-does-du-report-a-size-of-0-for-some-non-empty-files-on-a-hfs-partition http://unix.stackexchange.com/questions/96491/why-does-du-re... The last answer (marked for 0 points of course) is probably correct in this case. The file fits in the extended attributes.

thought_alarm 11y ago

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.

andrewmcwatters 11y ago
I'm tired of having discussions with people on HN for this very reason. It's such a joke.
- dang 11y ago
  Please stop posting comments that lower the quality of the site even further. Instead, post nothing or find a way to improve the discussion. Quite a few users have done so in this very thread, so you needn't look far for inspiration.
Profan 11y ago
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!
- andrewmcwatters 11y ago
  Searching for meaning rather than judging something over face value is a sign of an educated person. You would expect more of those types on HN, but instead there's seemingly a crowd of predominantly hyperopinionated tinkerer-types.

rbanffy 11y ago

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.

tshtf 11y ago

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-and-221-and.html http://git-blame.blogspot.com/2014/12/git-1856-195-205-214-a...) and one in Apache a few years earlier.

larvaetron 11y ago

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

jbverschoor 11y ago

OH I miss the BFS

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

mwfunk 11y ago

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.

justizin 11y ago

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 11y ago
FYI - Steam requires a case-insensitive filesystem. :-( https://support.steampowered.com/kb_article.php?ref=8601-RYPX-5789 https://support.steampowered.com/kb_article.php?ref=8601-RYP...
- bluedino 11y ago
  So do Adobe products. https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html https://helpx.adobe.com/creative-suite/kb/error-case-sensiti...
niccaluim 11y ago
It's got nothing to do with copyright. Classic Mac OS, from which HFS+ descends, happily copied both forks of a file for you. I'd be shocked if OS X's Finder didn't also copy both forks. I believe cp also supports them. And you can access them on the command line by appending "..namedfork/rsrc" to the filename. Although resource forks were just another data stream at the filesystem level, the OS treated them as structured data, with record types and IDs. They were used to store user interface elements--icons, pictures, window definitions, dialog boxes, etc.--as well as string lists, version information, and, yes, fonts. Even the executable was stored as a resource (M68k code that is; PowerPC binary was in the data fork). Applications could define their own resource types too. As another poster points out, this scheme helped applications manage memory by only loading into RAM the resources it actually needed at any given time.

trollian 11y ago

I miss ResEdit...

mehrdada 11y ago

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

jcsiracusa 11y ago

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_Model.txt http://www.folklore.org/StoryView.py?story=The_Grand_Unified... 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).

mdip 11y ago

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 11y ago
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=Font_Manager.txt 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)

sabujp 11y ago

HFS+ is "modern".

glhaynes 11y ago

"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."

niccaluim 11y ago

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

iSnow 11y ago

The kids today - know nothing about resource forks. Probably have never seen ResEdit either. How do you even build applications?

mpweiher 11y ago

>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