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