Hard/Symbolic Links [was: Re: r7347]

Christian Wurst christian.wurst at gmail.com
Fri Apr 11 04:50:09 PDT 2008

This is an interesting topic and immediately caught my attention when
I read it. Hopefully I don't step on anybodys toes by replying to this
before Ag states his opinion. Apologies if that is the case.

On Thu, Apr 10, 2008 at 11:45 PM, Randy McMurchy
<randy at linuxfromscratch.org> wrote:
>  In your mind, what is the difference between a hard link and
>  a symbolic link?

As far as I understand it the difference between hard and symlinks is
(simply put): While the hard link is just a file with two names, the
symlink is a file which points to another file. I'll use vim as an
example, with vi as a hard/symbolic link to it.

vi is a hard link: vim and vi have the same owner and group and the
same permissions. One can delete vi or vim, starting vim (the editor)
will still work using the other filename (i.e. vi in case vim was

vi is a soft link: vim and vi can have different owners and groups and
different permissions. If someone deletes vim, the symlink (vi) points
to an non-existing file. The editor can't be started anymore.

>  In your mind, when would a hard link ever be necessary?

Thus a hard link can only be necessary if I want

1.) that the file and the link can't be distinguished and/or
2.) must have the same owner/group and permissions and/or
3.) deleting one of the both doesn't affect the other.

For binaries (vim for instance) 3) is an interesting feature, while 1)
and 2) don't really get in the way. (Why would I want that someone can
invoke vi, but not vim or vice versa? It's the same binary.). But
creating symlinks in this case seems to be the {,B}LFS way of allowing
users to use both commands - and it works (no surprise! :) ). I can't
tell for sure, but I guess that the reason why symlinks are used is
that they allow more flexibility and - if the reader doesn't derive
from the book - (almost) do the same.

Earlier, Randy McMurchy <randy at linuxfromscratch.org> wrote:
>  I'm not really in favor of changing author's code unless there is
>  really a reason to do it (makes something better, or fixes a problem).

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.



More information about the blfs-book mailing list