Homebrew

Ryan Schmidt ryandesign at macports.org
Tue May 18 06:10:45 PDT 2010


On May 18, 2010, at 07:57, Daniel J. Luke wrote:

> On May 18, 2010, at 8:48 AM, Ryan Schmidt wrote:
>> On May 18, 2010, at 07:45, Daniel J. Luke wrote:
>>>> Where do symlinks shine when compared to hardlinks?
>>> 
>>> They don't.
>> 
>> Well, symlinks would fix the Time Machine issue, wouldn't they? Hardlinks are indistinguishable (to Time Machine, anyway) from real second copies of files, so Time Machine backs up twice, doesn't it?
> 
> I don't know, there's no reason why Time Machine can't be hard-link smart, though. If you've noticed bad behavior, you should probably make sure you file a bug report with Apple (so it has a chance of getting fixed).

I don't use Time Machine; I don't know if this problem actually occurs. I thought I remembered someone saying on the list some time ago that it did.


>> With symlinks it wouldn't. Not saying we should switch back to symlinks, and I know we have a branch in progress that already fixes this a different way (right?) just pointing out a case where symlinks have an advantage over hardlinks.
> 
> The advantage being that a TM backup will take up a little less space (and be a little less broken when restored). The disadvantage being that it will re-expose all of the old bugs we saw in individual ports when we used symlinks.

Again, I wasn't suggesting we change MacPorts to go back to using symlinks instead of hard links. Andrea asked a general purpose question about the difference between symlinks and hard links, and your response made it sound like there was no reason to ever use symlinks, that they had no advantage at all. I was pointing out a case where they do, and that in fact, it's hard links, not symlinks, that are the peculiar/unusual entity to me; it would never occur to me to create a hard link (I would use a symlink, or if necessary a Mac OS alias). Even after using MacPorts for years and experiencing firsthand that its hard links do what they do just fine, hard links still feel strange to me. They don't fit neatly into my view of how filesystems work which was formed by years of experience on Systems 6, 7, 8, & 9.

Another problem with hard links is one that was discussed on a MacPorts list not long ago, about determining how much space the MacPorts prefix takes up. Both the "du" command and the Finder's Get Info window can't tell hard links from real files and misreport the size of the prefix by counting the hardlinked items twice. Symlinks wouldn't have this problem.




More information about the macports-dev mailing list