Live data from Hacker News

HFS+ is crazy

liminality.xyz

161–170 of 211 posts

Re: HFS+ is crazy

#161

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 mai…

I'm tired of having discussions with people on HN for this very reason. It's such a joke.

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.

Re: HFS+ is crazy

#162

Earlier quoted context omitted.

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…

It does not strike me as a sane design. You already have file extensions, unique prefixes (like those used by the 'file' command to identify files). Why would you use fs forks to differentiate between file types?

Mac OS Classic had no file extensions. I remember they felt like such a hack when switching to OS X, compared to the flexibility of resource forks.

Re: HFS+ is crazy

#164
post #72

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…

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.

F2FS or YAFFS2 would be cool replacements.

Re: HFS+ is crazy

#165

Earlier quoted context omitted.

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…

It does not strike me as a sane design. You already have file extensions, unique prefixes (like those used by the 'file' command to identify files). Why would you use fs forks to differentiate between file types?

Actually, Classic Mac OS used type and creator codes, which were attributes on files, to identify filetypes, not resources.

Re: HFS+ is crazy

#166
post #78

Earlier quoted context omitted.

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 migh…

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 resou…

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.

Re: HFS+ is crazy

#167

Earlier quoted context omitted.

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

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…

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

Re: HFS+ is crazy

#168

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) - 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…

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

One maybe lesser-known use for ADS: FlylinkDC++ (and derivatives) have an option to store TTH hash data in the file's own ADS, instead of in a central hash store. It means that the hash data could be used by multiple applications, but, it's less I/O efficient to make thousands of these <4KB blocks everywhere.

Re: HFS+ is crazy

#169

Earlier quoted context omitted.

It seems you are knowledgeable on the topic, why not make your criticism a bit more constructive? Why are "multiple data forks/stream" needed and what are they used for? (I don't know very much about file systems)

It's essentially a way to gather more information concerning a file/application without needing to fill the overall filesystem with fairly irrelevant data. So it's a natural place for things like the third-party fonts a program needs, the data files that a program uses, the settings a program has, etc. For example, a game could have a save file that's simply named Blah.sav, but in the data streams, it could have Blah…

Which is basically doable with folders.

Re: HFS+ is crazy

#170
post #47

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!

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.

Post reply on HN