[coldtea]

>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 perhaps tooling).

[blakeyrat]

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.

[coldtea]

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

[digi_owl]

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

[coldtea]

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

[digi_owl]

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

[coldtea]

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.

[makomk]

No, the problem is that there were all kinds of interesting non-Unixy implementations of files out there and they were all incompatible with each other. For example, VMS supported file versioning and record-based files, neither of which Macs supported, but in turn had no way of supporting resource forks. Similarly, NTFS supports alternate data streams which can store a resource fork, but Mac Classic had no way of storing other alternate data streams. The Internet forced everyone to use Unix's idea of files because it's the only subset of functionality that actually worked between more than one platform.

[fzn]

On one hand, it was easy to overlook this issue, and you'd end up with catastrophic data loss (been there, done that).

On the other hand:

1. it's the sort of mistake you tend to learn quickly not to redo ;(

2. a variety of encoding schemes were pretty common, and usually integrated in Mac browsers, mail clients, ftp clients. See for example this page from the Fetch website (http://fetchsoftworks.com/fetch/help/Contents/Concepts/Uploa...), or the hexbin(1) man page.

My personal take on what killed MacOS is this.

The MacOS was, for the start, a clever pile of kludges, for 68K series CPUs. Hot patching of routines was how you fixed bugs, introduced support for new hardware, etc. (See https://en.wikipedia.org/wiki/Macintosh_Toolbox#Advent_and_i...) (Btw, a System 7.1 source code archive leaked years ago.)

I can imagine debugging and extending it became more and more painful. And core data structure choices (16-bit-friendly) might have been becoming wasteful as architectures came and went...

So Apple had people grinding at Copland (apparently didn't quite make it), and then NeXT was bought, .

TL;DR: IMHO, that's not the main point (not either a notable one, once you're educated about it). MacOS grew to a point where it became a fragile, quite complex, house of cards.

[treve]

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.

[coldtea]

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

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

[WorldMaker]

Well, in practice if more files had resource forks more tools would be smarter in how they operated on them, including making sure not to lose important forks.

> HTML upload form

The idea of a file doesn't change with resource forks: you upload the file as a whole and the thing uploads. Just as humble and simple. The onus is on the browser on the one side and server on the other not to drop the metadata.

The only other change might be in rare cases you might want to upload only a single fork in the file instead of the whole file. The old Mac Classic file picker had a way to this for advanced users, and there would be nothing stopping you from adding such an advanced option to any other file picker.

> or Git

Actually, something like git could probably make good use of something like resource forks if given the chance. For instance, the git pack format is essentially a relative to the resource fork format (a collection of a bunch of smaller objects wrapped into a single file). In a world of practical resource forks everywhere, you could presumably attach something like git packs of files to themselves, which could give you the benefit of a file being its own source control history without having to truck that information along as its own files/directories. (In which case you get the benefit of using that humble HTML upload form to much more easily upload a file and its entire source control history, rather than needing a dedicated git server... admittedly there would be performance trade-offs there though.)

[barkingcat]

yes I want to reemphasize coldtea's point. These resource forks are part of the core platform and the tools that need to use them have the code to be able to manipulate them.

Anyone who's ever worked with Macs - including software writers, tool writers, developers, know about resource forks - and it's fine because major tools have been rewritten to be resource fork aware.

Nothing's really gone wrong in the sense of reality and while there may be hiccups, you don't really see users actually complain about resource forks.

It's the hypothetical case where "people actively start storing critical data ..." etc. In this case, those people haven't done their homework about the mac platform. Like the Original Post of this HN thread - this person clearly hasn't read the docs re: resource forks and is hacking around, assuming that the mac should be like any of the platforms they've used before, and complaining when it is different.

There are also extensive - majorly detailed documentation from Apple themselves re how resource forks are used and in which circumstances:

https://developer.apple.com/search/?q=%22resource%20fork%22

That gives a ton of hits. Just read the docs. Really.

Again, I pull out the old Windows example moving from FAT to FAT32

8.3 filenames -> Long filenames contains a backwards compatible way to truncate long filenames back down to 8.3. So what if someone stores critical information in the long filename that is suddenly lost when round-tripping through an OS that doesn't understand long file names? SHOCK!! HORROR! Reality is no one does that. End of story.

https://en.wikipedia.org/wiki/Long_filename

Platforms are different! just learn what's different so that you don't get caught unaware.