site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -m -- http://www.plasticsfuture.org _______________________________________________ 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... At 18:52 Uhr -0400 2006-06-27, Dan Shoop wrote: At 9:45 PM +0200 6/27/06, maurits wrote: At 15:17 Uhr -0400 2006-06-27, Dan Shoop wrote: ditto should (expectedly) mimic the Finder's copy functionality. As such an argument could be made that since the geometry of the files are different the ACL from one file shouldn't apply to the other. what do you mean by geometry? I fail to see how ACLs should be handled any different from permissions. Geometry is locational information with respect to the filesystem. (This is not metadata any more than facing right or left doesn't change my location.) That is pathA/file and pathB/file have different geometries. ACLs are geometric in nature. For instance they have notions of inherence based on geometry. However this geometry can only logically be relative to the volume. I'm not an expert in ACLs, but my limited knowledge tells me you're mistaken in this respect. ACLs by themselves are self-contained, there is no notion of context dependence. Only when files are created, they possible inherit some ACLs from their parents. So when you copy a file from A/ to B/ with cp -p, all only the explicit ACEs are copied over, and the file inherits new ACEs according to its new parents. That's the logic in copyfile_security(). What's wrong with that? Also I don't see how ditto should behave differently from cp -Rp (apart from the fact that ditto hasn't been updated in 10.4, apparently, probably for time reasons). This email sent to site_archiver@lists.apple.com