[mhurron]

And OS X could do the same thing with the resource fork if they wanted to instead of never forgetting.

Seems to me this would be a better way to do it, you're reading the resource fork for the file anyway, why also make a sqlite query as well?

[klodolph]

No, the resource fork is dead for good reasons. (1) The resource fork is fragile and easily corrupted, like the Windows registry in the bad old days. (2) Four-character namespaces suck. (3) 24 MB limits suck. (4) Extended attributes and bundles are better in every conceivable way.

The resource fork was designed for a different world. (A) In the old days, there was a blurry line between OS and app, so there was no reason to make the resource fork "opaque". Without opacity, there is no graceful way to use it in a preemptive multitasking environment. (B) In the old days, pointers were 24 bits. The high 8 bits didn't go anywhere, so people used these high bits to store extra data. Resource forks make use of 24-bit quantities for this reason — which went out of favor when Macs with the 68020 were introduced in 1987. (C) The real feature of resource forks was to reduce the disk space usage and load times when you have lots of small pieces of data, but — data is bigger and we have better archive formats.

So yeah, extended attributes are the way to go.

[hosay123]

There is also a maximum of one officially supported fork per file (i.e. in a single format), and even a single stored byte will occupy a full block. On HFS+ attributes are written as individual records directly to a per-filesystem b-tree, so wastage is no worse than any other metadata. HFS+ also has named forks but they were never a supported feature AFAIK