site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com It's not my intention to ever intentionally create directory hard links. On Dec 12, 2007, at 4:37 PM, Jordan K. Hubbard wrote: - Jordan On Dec 12, 2007, at 3:12 PM, Rosyna wrote: --- Sincerely, Rosyna Keller Technical Support/Carbon troll/Always needs a hug Unsanity: Unsane Tools for Insanely Great People It's either this, or imagining Phil Schiller in a thong. _______________________________________________ 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 is true. And directory hard links are a concept I do not like for various reasons. So, I was really pleased when people at WWDC and other places repeatedly said (or strongly implied) Time Machine used a private function to make directory hard links, that this SPI would not be exposed, and developers should not be making directory hard links. But alas, if some developer has code that depends on link() failing with EPERM for a directory (they don't check the path first), their code will magically start working on HFS+ on 10.5. My hope was that time machine would call some super private function (like hfs_super_private_link) that exposes hfs_vnop_link() to do its dirty deeds that no one else could, should, or can call. You're not supposed to notice that directory hard links are now allowed (for Time Machine's exclusive use) so it's neither an error in the documentation or an error in the function. The error is that you're being too nosy. :-) The actual implementation of link() on 10.5 allows for directory hard links on HFS+ as long as they follow these rules: This email sent to site_archiver@lists.apple.com