Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HFS+ is crazy

liminality.xyz

Post reply on HN
Print view View original

181–190 of 211 posts

Re: HFS+ is crazy

#181

Post by chetanahuja »

marssaxman wrote: post #154
chetanahuja wrote: post #124

Earlier quoted context omitted.

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…

It's not broken, it's just old. It's a legacy technology from the original Macintosh system released in 1984 - before it was even called "Mac OS". Your "reasonable user expectations" are conditioned by three decades of experience with systems that largely didn't exist when the Macintosh resource fork was designed.

Yes the filesystem is from the 80's and from a period where Unix filesystem model had perhaps not gained the dominance that it did in later years. The question is why is it still being used in OSX 15 years after a complete redesign of the system around a Unix kernel?

Re: HFS+ is crazy

#182

Post by coldtea »

digi_owl wrote: post #155
coldtea wrote: post #150

Earlier quoted context omitted.

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

http://without-systemd.org/wiki/index.php/Arguments_against_...

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

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

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

Re: HFS+ is crazy

#184

Post by marssaxman »

chetanahuja wrote: post #181
marssaxman wrote: post #154

Earlier quoted context omitted.

It's not broken, it's just old. It's a legacy technology from the original Macintosh system released in 1984 - before it was even called "Mac OS". Your "reasonable user expectations" are conditioned by three decades of experience with systems that largely didn't exist when the Macintosh resource fork was designed.

Yes the filesystem is from the 80's and from a period where Unix filesystem model had perhaps not gained the dominance that it did in later years. The question is why is it still being used in OSX 15 years after a complete redesign of the system around a Unix kernel?

They had to support HFS+ in order to convince existing users to upgrade. The first five releases of OS X had something called "Classic mode" which was basically an instance of OS 9 running as a process, so that people could continue using their pre-OS X apps. It took six years before enough developers had upgraded that Apple could stop supporting Classic. And Classic, of course, was all about HFS+. So Apple could either backport this hypothetical unix-style filesystem to OS 9, do something kludgerous with single-machine file-sharing, require all users to partition their drives and keep everything they wanted to use in Classic on the HFS+ partition (a tough sell!), or just use HFS+ and get on with it. They wanted to stay afloat, so they stuck with HFS+, and here we are today.

Re: HFS+ is crazy

#185

Post by btilly »

JupiterMoon wrote: post #180
btilly wrote: post #166

Earlier quoted context omitted.

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

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

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

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

Re: HFS+ is crazy

#186

Post by itomato »

blakeyrat wrote: post #74
stefantalpalaru wrote: post #44

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…

Had you been there, you might think different.

Re: HFS+ is crazy

#187

Post by tjohns »

Uberphallus wrote: post #169
Sanddancer wrote: post #104

Earlier quoted context omitted.

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.

Sure, but if you're browsing the filesystem directly, it looks much cleaner.

Remember that MacOS users spend much more time working directly with the filesystem, because (recent developments with Launchpad aside) there's no analog to Windows' Start Menu. Literally everything is done by navigating directly through your hard drive in Finder. So keeping related files nicely bundled together and tidy is a bigger priority.

(You can also do neat things, like record whether a file was downloaded from the Internet, and from where -- and use that data to display a security warning when a foreign file is first opened. This would be very cumbersome to implement without extended attributes or resource forks.)

Re: HFS+ is crazy

#188

Post by yrro »

duskwuff wrote: post #92
coldtea wrote: post #32

Earlier quoted context omitted.

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

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.

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

Re: HFS+ is crazy

#190

Post by Vendan »

tjohns wrote: post #187
Uberphallus wrote: post #169

Earlier quoted context omitted.

Which is basically doable with folders.

Sure, but if you're browsing the filesystem directly, it looks much cleaner. Remember that MacOS users spend much more time working directly with the filesystem, because (recent developments with Launchpad aside) there's no analog to Windows' Start Menu. Literally everything is done by navigating directly through your hard drive in Finder. So keeping related files nicely bundled together and tidy is a bigger priority…

so don't go into the app's directory and you don't see the extra files. Keep in mind, the start menu on windows is LITERALLY just a set of folders in your home directory, with a somewhat nice interface on top of them.
Post reply on HN