site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com El 20/09/2006, a las 12:51, Steve Checkoway escribió: Hard links as implemented in 10.0: http://www.wsanchez.net/papers/USENIX_2000/ Information on hard links (to directories!) in Leopard: http://arstechnica.com/staff/fatbits.ars/2006/8/15/4995 _______________________________________________ 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... I disagree. While both of those properties of links are true, I wouldn't say that's the difference. As I'm sure you well know, a hard link is just another link to the same inode with a different path. I know that either HFS or OS X (I'm not sure which) has issues with files that have at any point been hard linked whereas a symbolic link is a different file which points to a path (as can be read by readlink(2)). There is no difference between an original link to a file and a hard link to the file. For all intents and purposes, they are the same file. This is not true of a symlink. HFS+ lacks support in the volume format for hard links, a standard feature of UFS. Initially, the attempted creation of a link to a file would yield a "not supported" error. We had discussed some "80%" solutions, such as creating symbolic links instead, but the semantics of symbolic links are significantly different. For troubleshooting reasons it is preferable to fail at link creation time than at some later time due to problems related to these semantic differences. The problem is that there is a significant amount of software which breaks if hard link creation fails, and some of that software needs to be redesigned if hard links cannot be used. In order to accommodate this software, we now emulate hard links by creating a "kernel-level" symbolic link which is visible only to and interpreted by the HFS+ file system. This was necessary due to the lack of support in the volume format. The resulting behavior is very similar to that of hard links when viewed from above the kernel, though they are relatively inefficient in comparison. Apple added traditional hard links (that is, hard links to files) to HFS+ back before Mac OS X 10.0 was released. In Leopard, HFS+ supports hard links to directories as well—an ability wholly alien to any other Unix-like operating system that I can think of. This is how Time Machine builds its sparse trees. The very first backup is a full copy. All subsequent backups contain hard links to the unchanged portions of the previous backup. This email sent to site_archiver@lists.apple.com