10

I understand the technical difference between symlinks and hardlinks, this is a question about their use in practice, particularly I'm curious to know why both are used in seemingly similar conditions: the /bin directory.

Here's a fragment its listing on my system:

~$ ls -lai /bin total 10508 32770 drwxr-xr-x 2 root root 4096 Jun 14 11:47 . 2 drwxr-xr-x 28 root root 4096 Sep 6 13:15 .. 119 -rwxr-xr-x 1 root root 959120 Mar 28 22:02 bash 2820 -rwxr-xr-x 3 root root 31112 Dec 15 2011 bunzip2 127 -rwxr-xr-x 1 root root 1832016 Nov 16 2012 busybox 2820 -rwxr-xr-x 3 root root 31112 Dec 15 2011 bzcat 6191 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzcmp -> bzdiff 5640 -rwxr-xr-x 1 root root 2140 Dec 15 2011 bzdiff 5872 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzegrep -> bzgrep 3520 -rwxr-xr-x 1 root root 4877 Dec 15 2011 bzexe 6184 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzfgrep -> bzgrep 5397 -rwxr-xr-x 1 root root 3642 Dec 15 2011 bzgrep 2820 -rwxr-xr-x 3 root root 31112 Dec 15 2011 bzip2 2851 -rwxr-xr-x 1 root root 10336 Dec 15 2011 bzip2recover 6189 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzless -> bzmore 5606 -rwxr-xr-x 1 root root 1297 Dec 15 2011 bzmore

I indented the hardlinks to the same inode for better visibility. So are symlinks used in case of bzcmp, bzegrep, bzfgrep, bzless and hardlinks in case of bzip2, bzcat, bunzip2?

They are all regular files (not directories), reside inside one filesystem, are system utilities and are even made for working with the same thing: bzip archives. Are the reasons for use of hardlinks/symlinks in this particular case purely historical or am I missing something?

Clarification of my question:

I'm not asking about:

  • The technical differences between symlinks and hardlinks
  • The theoretical advantages and disadvantages each of them

These questions have been addressed in other threads on SO. I'm trying to understand why different decisions were made in a specific case: for a group of related system utilities. Technically, they all could've been symlinks or they all could've been hardlinks, both options would work (and in both cases a program can still figure out how it's been invoked via argv[0]). I want to understand the intent here if there is any.

Related:

Improve this question
3
  • I think that's up to the package maintainers to decide. f.e. I run gentoo, and in my /bin the third column of ls -lai is always 1 so it seems to only use soft links. What distro do you use? Commented Sep 25, 2013 at 8:56
  • I use Ubuntu 12.04 Commented Sep 25, 2013 at 9:38
  • 1
    At first glance it looks to be some rule of type: "hardlinks for binaries, symlinks for scripts/wrappers". Commented Sep 25, 2013 at 11:11

2 Answers 2

Reset to default
5

Why use hardlinks vs. Symbolic links

There are primarily 3 advantages of using hardlinks over symbolic links in this scenario.

Hard links

  1. With a hard link, the link points to the inode directly.
  2. Hard links are like having multiple copies of the executable but only using the disk space of one.
  3. You can rename either branch of the hard link without breaking anything.

Symbolic links

  1. The link points to the object (which then in-turn points to the inode).
  2. They can span filesystems, whereas hardlinks cannot.

Advantages of linking in general

These links exist because many executables behave differently based on how they were called. For example the 2 commands bzless and bzmore are actually a single executable, bzmore. The executable will behave differently depending on which names was used to invoke it.

This is done for a variety of reasons. Here are some of the more obvious ones:

  1. Easier to develop a single executable rather than many
  2. Saves disk space
  3. Easier to deploy

Why are both being used?

The choice of either, in this particular application, is moot. Either can facilitate the feature of acting as an alias so that a single executable can be overloaded. That's really the key feature that is getting exploited by the developers of the various programs here.

In looking at the FHS (Filesystem Hierarchy Standard) even specifies it this way, that it can be either.

excerpt

If /bin/sh is not a true Bourne shell, it must be a hard or symbolic link to the real shell command.

The rationale behind this is because sh and bash mightn't necessarily behave in the same manner. The use of a symbolic link also allows users to easily see that /bin/sh is not a true Bourne shell.

...

...

If the gunzip and zcat programs exist, they must be symbolic or hard links to gzip. /bin/csh may be a symbolic link to /bin/tcsh or /usr/bin/tcsh.

References

Improve this answer
6
  • Yeah I understand that, thanks, but why sometimes symlinks are used, and sometimes hardlinks are used? What you described would work the same way in both cases Commented Sep 25, 2013 at 9:39
  • @DmitryPashkevich - OK I've refactored my answer, let me know if that's better. Commented Sep 25, 2013 at 9:53
  • Maybe I'm asking a dumb question but I feel it's still unanswered :) Yes I'm familiar with technical differences and advantages/disadvantages of the two kinds of links. I'm trying to understand a specific case: why am I seeing BOTH hardlinks and symlinks in my /bin/ directory? Why didn't the developers of these utilities stick to one link type? Commented Sep 25, 2013 at 10:43
  • Edited my original question to (hopefully) clarify it Commented Sep 25, 2013 at 10:51
  • @DmitryPashkevich - added some additional content. Let me know if it helps. Commented Sep 25, 2013 at 11:36
5

It seems you're trying to figure out, from existing practice, whether there is a nontechnical rule that tells you which kind of link to use. (I say nontechnical because you already know the technical reasons to use one over the other.)

The answer is, there is no other rule. This example you've pointed out from Ubuntu's bzip2 package just goes to show that a lot of developers mix them without a whole lot of forethought. This is because there is no strong guidance other than the technical differences, and those differences are small.

Personally, I prefer to use symlinks, always, because I'm willing to pay for their tiny overhead in exchange for their self-documenting nature.

Other developers will choose hard links for the tiny efficiencies they provide.

This issue is a lot like spaces vs. tabs or dynamic vs. static typing or Emacs vs. vi, save that it isn't interesting enough to spark a holy war. Like the more interesting battles, there are reasons to choose either option, but unless you have someone telling you which one to use, you get to choose the one that makes more sense to you.

Improve this answer
1
  • 1
    Thanks for sharing your perspective! I think the "self-documenting" nature of symlinks is something that's often overlooked Commented Sep 25, 2013 at 13:22

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.