[danso]

Kind of brilliant, actually. Not the fix or the tracking method...just that I knew subconsciously that if OSX could know to warn me that I'm trying to open up a file downloaded from the internet (and which webpage it came from), then it must have some way of tracking it that supersedes the standard browser wipe. But I just never thought to look around for it.

[axusgrad]

Windows will warn you about files downloaded from the internet, too. It uses "Alternate Data Streams" feature of NTFS to mark the file. I suppose once you delete the file, the alternate data stream is gone as well. From what I read, alternate data streams were made for compatibility with a Mac filesystem!

[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

[ashmud]

Deleting the file also deletes the stream (in as much as deleting a file marks it as OK to overwite). Scott Hanselman blogged several ways to remove streams in 2007 (http://www.hanselman.com/blog/RemovingSecurityFromDownloaded...).