Live data from Hacker News

HFS+ is crazy

liminality.xyz

141–150 of 211 posts

Re: HFS+ is crazy

#141
post #121

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

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

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

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

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

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

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

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

Re: HFS+ is crazy

#142
post #128

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

FYI - Steam requires a case-insensitive filesystem. :-( https://support.steampowered.com/kb_article.php?ref=8601-RYP...

So do Adobe products.

https://helpx.adobe.com/creative-suite/kb/error-case-sensiti...

Re: HFS+ is crazy

#143

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…

Conflating extattrs with HFS style resource forks doesn't really make sense. Extended attributes are just that... attributes. They are not the main "data" of the file. Each and every unix file system has some attributes to begin with (permissions, timestamps etc.) and they vary from filesystem to filesystem (e.g., setuid bit, immutable bit etc.). User supplied attributes just extends this concept in a natural way. Al…

Just a datapoint: Macs have been sending files via the Internet with resource forks for a long time, basically since the invention of the Macintosh: https://en.wikipedia.org/wiki/BinHex

Resource forks are basically legacy from the original MacOS, and something that's being retained for compatibility, not something that's really a current design. The current replacement of resource forks is bundles, where a directory masquerades as a file in the GUI.

There are lots of reasons to hate on HFS+, but I wouldn't consider this the most important one.

Re: HFS+ is crazy

#144
post #45

Earlier quoted context omitted.

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

Yeah. And if I recall correctly, in very old versions of the Mac OS. You actually installed things like fonts into your system by copying the resource fork data from the font file into resource fork of the (singular) "System file" which contained the entire OS (except for the shell).

Oh, this is a fun subject.

That the system file contained the "entire OS" is a bit of a misconception: the bulk of the OS primitives are stored in ROM, and the system file mostly contained diffs between the OS version stored in each machine's ROM and the current OS. Eventually, the practice of storing all these diffs in the system file stopped with 7.1.2, and they began releasing the diffs as seperate files called "enablers" (before then, the introduction of any new model required a new version of the OS to be released to contain that model's diffs). It also contained a number of resources that are too big to go in ROM, such as sounds, fonts, and "desk accessories".

Let's talk desk accessories, because they're cool and they exemplify the most interesting properties of classic Mac OS. Originally, Mac OS was purely a single-tasking OS. But Apple knew that people would be very frustrated if they couldn't run small apps, like a calculator, over the active application. They got around this with an applet system they called "desk accessories", or DAs for short. DAs were technically coded as device drivers, and they were stored in the system file as resources of type DRVR, just like any other device driver. The system file populated the Apple Menu with a list of installed DAs, and when you selected one, it would patch the DA's code directly into the running application's memory, giving the illusion of multitasking.

Fonts, too, were stored in the system file as resources of type FONT. Apple honestly never expected third parties to write their own DAs or fonts, which is why they opted for such a hardcoded solution. But people did so anyway, and they wrote particularly ugly hacks to do it. So Apple caved and wrote a utility called the Font/DA Mover, which allowed you to install FONT and DRVR resources from other files into the system file. It also allowed you to do the opposite, and extract those resources out of the system file and into new files (IIRC, the system file had a limit of how many resources of each type it could have, so power users had to have some way to swap things out). Apple also introduced the word "suitcase" to refer to files that consisted entirely of FONT or DRVR resources and existed solely as holding pens for fonts and DAs that weren't installed into the system file.

System sounds, too, were stored in the system file as resources of type SND (actually "SND ", as names had to be four characters), but there was so little interest in custom system sounds at the time that Apple never made a utility for it (third parties provided them, though).

A lot of this changed in System 7. First off, System 7 came with built-in coöperative multitasking, so DAs were no longer necessary. DAs were evicted from the system file, and Apple implemented a clever hack so DA suitcases could be directly executed as if they were programs, by causing them to be patched into the Finder's memory space when double-clicked in the Finder or run from the Apple Menu. Accordingly, the Apple Menu was no longer generated by the system file but reflected the contents of a folder under the System Folder called "Apple Menu Items", which typically consisted of aliases (another new System 7 feature: aliases were kinda like symlinks, but smarter). Second, the Font/DA Mover was obsoleted, and custom sounds endorsed, by giving the Finder the ability to browse the FONT and SND resources of the system file as if the system file was a folder, allowing the user to drag and drop font suitcases and sounds files in and out of the system file. Apple also redefined the word "suitcase" to now mean "any file whose resource fork can be browsed in the Finder like it was a folder": the system file was now listed in the Finder as having a file type of "suitcase", and the contents of font suitcases could now be browsed as if they were folders (users could now drag and drop individual FONT resources between suitcases, and individual font resources within a suitcase could be double-clicked to show a preview of the font). DA files were no longer described as "suitcases", as they were simply displayed to the user as if they were executable programs. The DA API was also deprecated, and Apple began telling developers to just write regular programs instead.

System 7.1 changed this further, by pulling fonts out of the system file, leaving only system sounds. Instead, the System Folder now contained a directory named "Fonts", which was filled with font suitcases. IIRC, at some point, they also extended the "suitcase" functionality of the system file to allow keyboard layouts to be dragged and dropped in and out of the system file, but I don't remember too much about that.

The technical details of Classic Mac OS were really interesting.

Re: HFS+ is crazy

#145

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…

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

Actually, I believe OS X does this for small files in order to not burn a whole filesystem block on a sub 1k file.

"In Mac OS X Snow Leopard 10.6, HFS+ compression was added. In open source and some other areas this is referred to as AppleFSCompression. Compressed data may be stored in either an extended attribute or the resource fork.[13] When using non-Apple APIs, AppleFSCompression is not always completely transparent."

https://en.wikipedia.org/wiki/HFS_Plus#History

Re: HFS+ is crazy

#146

Earlier quoted context omitted.

Yeah. And if I recall correctly, in very old versions of the Mac OS. You actually installed things like fonts into your system by copying the resource fork data from the font file into resource fork of the (singular) "System file" which contained the entire OS (except for the shell).

Oh, this is a fun subject. That the system file contained the "entire OS" is a bit of a misconception: the bulk of the OS primitives are stored in ROM, and the system file mostly contained diffs between the OS version stored in each machine's ROM and the current OS. Eventually, the practice of storing all these diffs in the system file stopped with 7.1.2, and they began releasing the diffs as seperate files called "e…

enablers are only for machines released after the version of Mac OS was originally released.

Re: HFS+ is crazy

#147

Earlier quoted context omitted.

I mean, there is http://open-zfs.org/wiki/Main_Page and FreeBSD has been proving the implementations reliability for some time now. Apple could adopt it. They don't. That's probably because the desktop OS is on life support, and there are indications Apple wants to abandon it in favor of a migration to a wholly iOS model.

And what file system does iOS use? I believe it is HFS+. So, if there was a compelling reason to switch from HFS+ to ZFS, it would apply equally to an iOS-only future at Apple. (Although I see no indications of such a future.) I think it is more likely that: a) Apple is working on their own new filesystem, optimized for their use. A company that invests in their own chip designs can certainly invest in their own file…

As I understand it, ZFS would be too heavyweight for iOS. Its memory usage [1] is much higher than most other file systems.

iOS uses HFS+ in case sensitive mode ("HSFX"), by the way.

[1] https://wiki.freebsd.org/ZFSTuningGuide

Re: HFS+ is crazy

#148

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…

Apple added support for extended attributes to HFS+ in Mac OS X 10.4 Tiger: http://arstechnica.com/apple/2005/04/macosx-10-4/7/#extended... Today, resource forks are actually exposed through the extended attributes interface: http://arstechnica.com/apple/2013/10/os-x-10-9/9/#tags-imple... You can see the source code for all this in Apple's Darwin open source repository. Example: http://opensource.apple.com/source/xnu…

John, Have you heard any rumblings from within Apple about a new filesystem? Is there any hope?

Re: HFS+ is crazy

#149

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

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.

Re: HFS+ is crazy

#150

Earlier quoted context omitted.

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

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

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

Post reply on HN