Live data from Hacker News

HFS+ is crazy

liminality.xyz

81–90 of 211 posts

Re: HFS+ is crazy

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

Great comment. Is there anywhere I can read about how it worked and what it was used for before it became a "veriform appendix"? It seems really interesting.

This article by John Siracusa was written right around the time Apple was ditching use of resource forks in OS X and contrasts some of their uses with how it's done today: https://news.ycombinator.com/item?id=10678261

Re: HFS+ is crazy

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

Re: HFS+ is crazy

#83

Earlier quoted context omitted.

Maybe a lot of us (as I did, to be honest) thought that Mac resources went away with the advent of NextStep/OSX.

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.

AND many Carbon apps, even ones which wouldn't run on Classic Mac OS, would still load resources from a resource fork.

Re: HFS+ is crazy

#84
post #27

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

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

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.

Re: HFS+ is crazy

#85
post #78

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…

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…

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.

Re: HFS+ is crazy

#86

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

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.

Re: HFS+ is crazy

#87

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…

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)

Re: HFS+ is crazy

#89

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…

Arguably, NTFS implemented alternate data streams primarily to support Mac resource forks.

Dave Cutler's team writing NT came from VMS which has multi-version files which are pretty much the same as multi-fork files.

Re: HFS+ is crazy

#90
post #27

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

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

Who cares if it's a fine idea in theory, when in reality it's completely unpractical. What you call 'worse' is a model that works.

Files showing the wrong size are a very small part of the problem. If people actively start storing critical data in resource forks (as it was done in the case of the font), a lot of other things will break. Just think of the humble HTML upload form or Git.

Almost everywhere a file is considered to be a name + it's contents. Meta-data is wide-spread, but it there's never any real data-loss when it's discarded.

Post reply on HN