Hard/Symbolic Links [was: Re: r7347]

Ag. D. Hatzimanikas a.hatzim at gmail.com
Fri Apr 11 08:24:53 PDT 2008

On Thu, Apr 10, at 04:45 Randy McMurchy wrote:
> Ag. D. Hatzimanikas wrote these words on 04/09/08 10:28 CST:
> > On Tue, Apr 08, at 02:32 Randy McMurchy wrote:
> >> ag at linuxfromscratch.org wrote these words on 04/05/08 02:19 CST:
> >>> Replaced with symlinks the hard links to red and its man page
> >> Why was this done?
> >>
> >> 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 am not either, but this seems a case for an unnecessary hard link
> > (unless I am missing something obvious, so feel free to be pedantic).
> For the sake of the discussion and perhaps some knowledge gained,
> I'm continuing on.

I am not sure, while we keep arguing over a trivial matter
contributes to a broader knowledge. Because quite frankly, both
solutions works fine, without significant advantages to any of the both

The small differences, is the way we do the package management, because
in reality we *do* package management in the Book, don't we?
The prefix of our choice is /usr, (some/many)times we change locations
of executables using for example --prefix=/bin, we create symbolic links
to libraries, we do interventions! But even if we didn't even one of
those interventions, we still do package management, which is 'by definition'
our work.

We are managing the installation of a package.

For example, I am totally missed the hard link to ed/red (man
page)/executable because the format sequence I used to track the package
missed the hard link. And one yet another reason to change the execution
of the ln(1)command is the absence of verbosity (-v switch), which made
me to loose the creation.

stat(1) for example when it reports about a file it doesn't give
any obvious information, if a file is a hard link or not.
You can see it only if you check the number of links  or if you check
the inode ("%i") of the prototype and the hard link's inode number ("%h"),
because both share the same inode.

So lets say that you move the ed binary to /bin, because you need ed
while booting and you have / (root) in a different file system.
Then you will discover that red is broken.

> I'm curious to know what you mean by "unnecessary hard link"?
> In your mind, when would a hard link ever be necessary?

Sorry if I made it sound like a really bad thing to do. Hard links
are not evil. :)
Even in package management has its use in occasions like an interpreter
or in a shell that want to have a fall back version or in applications
that invoked with different names in  the / (root) file system, that we
need to be present, i.e., {f,e}grep.

Some they use it as a cheap backup, or maildirs use it extensively
because the client doesn't have to see two inodes of a message so they
use hard links from tmp -> new.

> In your mind, what is the difference between a hard link and
> a symbolic link?

Here is a small demonstration of what I think is the difference.

[ag][484](~t/test)echo "this is a text" > parentfile
[ag][485](~t/test)ln -v parentfile hardlink
`hardlink' => `parentfile'
[1]ag][486](~t/test)ln -sv parentfile softlink
`softlink' -> `parentfile'
[1]ag][487](~t/test)cat hardlink
this is a text
[ag][488](~t/test)cat softlink
this is a text
[ag][489](~t/test)rm -v parentfile
removed `parentfile'
[ag][490](~t/test)cat hardlink
this is a text
[ag][491](~t/test)cat softlink
cat: softlink: No such file or directory

Now just tell me, why you - not the author - think that a link to the same
man page should be a hard link?
And why the red executable should be a hard link, when both hard/soft
links have the same behavior as it was demonstrated in the previous post
of mine?

Once again, I don't have a problem if you revert the commit. I will keep
doing it as I do, unless I will convinced that is not the right thing to
do. And because I don't want to do it in a different way that the way I
think is right then I give you again the authorization to do what you
think is best. Quite frankly no hurt feelings.


More information about the blfs-book mailing list