I've read this link, now I simply want to know why there are lots of hard link in /usr.

For example, in my Ubuntu server, installed git, I found the command git here: /usr/bin/git. I execute ls -l /usr/bin/git and get the output as below:

-rwxr-xr-x 119 root root 11178080 Mar  6 03:48 /usr/bin/git

As you see, there are 119 hard links...

Why do we need 119 hard links here? More generally speaking, as we have the environment variable PATH and the executable files have been put into /usr/bin/, also, we can create soft links for some reason of compatibility, we can execute them anytime and anywhere, why are there some hard links in usr?

Part of output of find /usr -samefile /usr/bin/git:


All of hard links of /usr/bin/git are found in /usr/libexec/git-core/.

closed as primarily opinion-based by muru, G-Man, Archemar, DarkHeart, jimmij Mar 7 '18 at 9:56

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • My Ubuntu 16.04 does not have 119 hard links to git. I get just 1 there. ... in fact, the only files which have hard links in my /usr/bin are a bunch of perl commands and python3.5, and that's probably some quirk of Perl and Python installation process. – muru Mar 6 '18 at 3:34
  • 1
    Even assuming 119 hard links, what's wrong with using hard links as long as it's in the same filesystem? Put another way: why should symlinks be used instead of hard links? – muru Mar 6 '18 at 3:40
  • FWIW on Arch I have three hard links to /usr/bin/git, to /usr/bin/git{,-receive-pack,-upload-archive}, and on Debian I have only one. – Sparhawk Mar 6 '18 at 4:30
  • 1
    Can you find which other files are links to it? find /usr -samefile /usr/bin/git should give you a list. The git package doesn't have them itself so I'm curious what does. – Michael Homer Mar 6 '18 at 4:39
  • An 11MB git binary makes it seem like this was installed from source, unstripped... – Stephen Kitt Mar 6 '18 at 5:36

The git links have nothing to do with the PATH, they’re a space-saving measure.

Generally speaking, in most cases for “installed” software, hard links are preferable to symbolic links when possible, because they’re more efficient and resilient. You’ll see quite a few binaries in /usr/bin with hard links, including perl, and that’s fine.

git packages do tend to use symbolic links instead, because of the large number of links involved and the problems that can cause. If you install git from source, it will use hard links by default if at all possible; you can disable that by adding NO_INSTALL_HARDLINKS=1 to the make install command’s arguments.


Often, a single binary with multiple related functions has multiple hard links, in order to let each function have a distinct, memorable command, and still not duplicate any code that all those functions might have in common.

Making the various functions of a single binary appear as distinct commands is also an easy, shell-independent way to make the functions TAB-completable: for example, in bash, if you only remember the first few letters of some command, just type the letters you remember and press TAB twice: you'll get a list of all commands with those initial letters.

Symbolic links can also be used for this, but if all the linked commands are expected to be in the same directory, hard links are the most space-efficient solution: instead of duplicating an entire file, or just using up an extra inode like a symlink might do (on some filesystems), a hard link occupies just a directory entry.

If you want to, you can easily make a script behave like this too:


case "${0##*/}" in
        # do something
        # do something else
        # output an error message, or perhaps usage instructions
  • I think that there is no "might" about it. Be confident! (-: Do you actually know of any filesystem formats where a symbolic link does not use an i-node? How do they square that with the necessary semantics of lstat()? – JdeBP Mar 6 '18 at 7:58
  • NFS, XFS and Btrfs are mentioned as examples where a symlink is not stored within an inode, but on closer inspection it seems to mean on those filesystems a symlink consumes an inode plus some other stuff. – telcoM Mar 6 '18 at 8:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.