101–110 of 211 posts
Earlier quoted context omitted.
Nope. It was originally done as part of OS/2 (Windows NT was sort of OS/3 - the next version of OS/2) and OS/2 had "extended attributes" - https://en.wikipedia.org/wiki/Extended_file_attributes#OS.2F... - so NT also needed them for compatibility.
Thank you! All these Mac people think Apple Invented Everything.
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.
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.
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.
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.
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)
Earlier quoted context omitted.
> 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.
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.
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.
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.
Earlier quoted context omitted.
> 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 con…
"Completely unpractical" is quite an exaggeration. OS X has used them for 15 years and things are working as they should for 99.9999 of the people in 99.9999 of the cases.
You'll read more complaints/confusion about way more standard POSIX/UNIXY features that you'll see about resource forks -- which are mostly hidden under the hood.
>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.
You mentioned "reality" but this is a hypothetical scenario.
People don't "start storing critical data in resource forks". Apple uses them for specific things it knowns how to handle and that they don't need to be shared outside HFS boundaries.
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)
For a practical example of the metadata, albeit not one from MacOS: BeOS had a similar concept of file attributes as key/value pairs, and some MP3 players would store ID3 tags in files. In a directory window, you could list any custom attributes as columns. When I was a BeOS user, that made it trivially easy to use the file system itself as my answer to iTunes: windows would show artist, album, song title, track number, and playing times (or whatever I wanted), and because you could search on custom attributes and then save those searches as virtual folders, you could easily set up the equivalent of smart playlists.