site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Mar 4, 2006, at 12:18 PM, Rob Braun wrote: - Jordan _______________________________________________ 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... It's true there is no complete standard, but there are similarities in approach. It appears to be a sort of newtonian approximation process to find the common middle ground. Apple appears to be trying the same newtonian approximation process to a completely different function. The treatment of the resource fork as an EA just doesn't fit with Apple's or anyone else's EA model. The resource fork is like a stream that is kinda sorta treated like an EA. TAdditionally, Apple has deviated in the treatment of EA namespace and external representation of the EAs. I don't think I ever argued that Resource Forks mapped cleanly and completely into the EA model - to be sure, they predated EAs by many years, so any feature overlap is purely coincidental. That said, I think Apple made the right decision to map them into the EA space rather than promoting two different first-class metadata access APIs going forward. We can't escape the ResourceFork legacy (too many things still assume it), nor can we deprecate the Carbon APIs for dealing with resource forks directly, but we can at least try to subsume one into the other in the POSIX namespace so as to slowly deprecate the "fork" (pun intended) going forward. Redhat Enterprise Linux and Fedora have both had SELinux enabled by default for quite a while now. SELinux uses EAs and ACLs rather extensively and encountered and solved many problems along the way. There are still many problems and Apple would do well to pay attention to avoid the pitfalls they have encountered. Interesting point. II'm still not sure about the size of the SELinux installed base, that is to say the number of people actually running SELinux with one or more active policies (BIBA, Port ACLs, whatever) and dealing with EAs/ACLs on a daily basis, but it does beg the question: What problems have they solved along the way and why do the various GNU command-line tools they must be using not support EAs or ACLs yet? We did a search for support like this before hacking the CLI tools ourselves, and we found no apparent attempts to grapple with the problems of EA preservation / transfer. This email sent to site_archiver@lists.apple.com