site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com In message <440E0A48.4090100@nicta.com.au>, Andrew White writes:
The same is true of resource forks. It's not "two files", it's one file with two (3 including system metadata) logical parts: one structured and one unstructured. The problem isn't the model, the problem is that it doesn't map well to Unix where a file is assumed to have one unstructured part only.
This is somewhat true, however... Nonetheless, it turns out to be a major source of bugs and confusion. A tiny fraction of the files I've ever dealt with have had both data and resource forks, except for the very weird PPC/68k binaries that existed under OS 9. Nearly everything else was EITHER a resource file OR a data file, in which case, a single fork would have been enough... And meanwhile, bundles have solved all the other problems. With the benefit of hindsight, bundles work better than forks. Anything a fork can do, a bundle can also do. Bundles can do many things forks can't. Bundles work transparently with unmodified code for archiving, because they fit into the hierarchy model. I think a lot of debates on this get bogged down because it's obviously true that the resource structures are cool, but in practice, most of what they're used for could be done with resource-only files. I mean, I guess I have to grant that "image thumbnails" are sort of cool, but it's a pretty specialized application. I don't think, in the long run, the cost in code maintenance has been remotely worth it. On the other hand, I don't necessarily think those engineers were wrong; they made an interesting decision, and we learned a lot from it. It's just that, now, we have this extra thing to deal with, forever. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com