• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ls -L [some symbolic linked file] not working
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls -L [some symbolic linked file] not working


  • Subject: Re: ls -L [some symbolic linked file] not working
  • From: Mailing list subscriptions <email@hidden>
  • Date: Wed, 20 Sep 2006 13:17:16 +0200

El 20/09/2006, a las 12:51, Steve Checkoway escribió:

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.

Hard links as implemented in 10.0:

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.

http://www.wsanchez.net/papers/USENIX_2000/

Information on hard links (to directories!) in Leopard:

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.

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      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >ls -L [some symbolic linked file] not working (From: David Hoerl <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: "Justin C. Walker" <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: Steve Checkoway <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: "Justin C. Walker" <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: Steve Checkoway <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: "Justin C. Walker" <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: Pelle Johansson <email@hidden>)
 >Re: ls -L [some symbolic linked file] not working (From: Steve Checkoway <email@hidden>)

  • Prev by Date: Re: ls -L [some symbolic linked file] not working
  • Next by Date: Where is sysctl.proc_native documented? Other sysctl values?
  • Previous by thread: Re: ls -L [some symbolic linked file] not working
  • Next by thread: leopard *.dmg file too big
  • Index(es):
    • Date
    • Thread