Hard/Symbolic Links [was: Re: r7347]
bruce.dubbs at gmail.com
Fri Apr 11 09:30:12 PDT 2008
Randy McMurchy wrote:
> Christian Wurst wrote these words on 04/11/08 06:50 CST:
>> I'd say making the book more consistent (in itself, but also with LFS)
>> is a reason too. If we do symlinks here (vim for instance) and
>> hardlinks there (ed), without a clear reason why, it might confuse
>> readers. If we differ from a standard way of doing things there should
>> be a reason - and it should be explained in the book why it is done
>> different in this case.
>> If my explanation about the differences of hard and symlinks is
>> correct, I can really live with both. But we really should have a
>> standard way to do it.
> Thanks for the input Christian! I'm also hoping Ag will comment,
> especially about "unnecessary" hard links.
> As far as your comment about "standard way to do it", I want the
> standard way to be: leave it as the package author wrote it, unless
> there is a problem with how he did it, or we can make it significantly
> better by changing it.
> Changing a hard link to a soft link doesn't fit in either of those
I agree with Randy's policy.
A couple of notes about hard vs soft (symbolic) links. All hard links must be
on the same file system. This is not true of soft links. Hard links means that
there can never be a "dead" or non-existing link target.
Second, you can not have a hard link to a directory. It has the potential to
create loops in the file system that would cause havoc. Of course, you can have
a soft link to a directory.
Third, symbolic links take up slightly more disk space than a hard link. A hard
link is only an inode. The soft link uses an inode and an additional block with
the path to the target files.
Fourth, directories contain hard links to each file contained in that directory.
Fifth, hard links can have different permissions and ownership. That does not
really make sense for symbolic links, even though it is possible.
More information about the blfs-book