Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know what hard links are, but why would I use them? What is the utility of a hard link?

share|improve this question
Excellent question. Thanks for putting it out here! – TheGeeko61 Jan 16 '12 at 1:21
up vote 35 down vote accepted

The main advantage of hard links is that, compared to soft links, there is no size or speed penalty. Soft links are an extra layer of indirection on top of normal file access; the kernel has to dereference the link when you open the file, and this takes a small amount of time. The link also takes a small amount of space on the disk, to hold the text of the link. These penalties do not exist with hard links because they are built into the very structure of the filesystem.

The best way I know of to see this is:

$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../

The -i option to ls makes it give you the inode number of the file. On the system where I prepared the example above, I happened to be in a directory with inode number 1069765, but the specific value doesn't matter. It's just a unique value that identifies a particular file/directory.

What this says is that when we go into a subdirectory and look at a different filesystem entry called .., it has the same inode number we got before. This isn't happening because the shell is interpreting .. for you, as happens with MS-DOS and Windows. On Unix filesystems .. is a real directory entry; it is a hard link pointing back to the previous directory.

Hard links are the tendons that tie the filesystem's directories together. Once upon a time, Unix didn't have hard links. They were added to turn Unix's original flat file system into a hierarchical filesystem.

(For more on this, see Why does '/' have an '..' entry?.)

It is also somewhat common on Unix systems for several different commands to be implemented by the same executable. It doesn't seem to be the case on Linux any more, but on systems I used in the past, cp, mv and rm were all the same executable. It makes sense if you think about it: when you move a file between volumes, it is effectively a copy followed by a removal, so mv already had to implement the other two commands' functions. The executable can figure out which operation to provide because it gets passed the name it was called by.

Another example, common in embedded Linuxes, is BusyBox, a single executable that implements dozens of commands.

I should point out that on most filesystems, users aren't allowed to make hard links to directories. The . and .. entries are automatically managed by the filesystem code, which is typically part of the kernel. The restriction exists because it is possible to cause serious filesystem problems if you aren't careful with how you create and use directory hard links. This is one of many reasons soft links exist; they don't carry the same risk.

share|improve this answer
About "The link also takes a small amount of space on the disk, to hold the text of the link." On modern file systems, no extra space is used to store the link path as the directory entry itself is used to store it, at least if the name isn't too long to fit. This is called "fast symlinks" – jlliagre Nov 25 '13 at 21:02
I would add that some applications do not know how to handle soft (sym)links, and thus hard links may be useful to avoid redundancies when configuring them by referencing to the same data/config files. An example is ioquake3, which can't follow symlinked pk3 files, but can follow hardlinked pk3 files. – gaborous Dec 16 '14 at 12:56
Also, if you delete the target of a symlink, the file is gone and the symlink is broken. An issue that does not exist with a hard link. – spectras Jun 18 at 22:31

One usage of hardlinks which is extremely useful is in incremental backups combined with rsync. It saves lot of space and makes the restoration procedure really easy. I use that approach for backup in my servers.

Take some time to read this explanation.

share|improve this answer
Thanks for the link, very interesting – n0pe Sep 14 '11 at 17:31

If after reading that wikipedia page your question is "why would I ever use them" then you don't understand what hard links are.

A link is a directory entry that points to blocks on disk. In other words every file on your system has at least one link. When you rm a file the actual system call is unlink(). It removes the directory entry. The blocks on disk haven't changed but the link is gone, thus the file is gone from the directory listing.

You personally may not ever use hard links, but they are all over your system. For example:

$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzip2

You can see that bunzip2, bzcat and bzip all use the same inode. In essence, it is one file with three names. You could have three copies of the file, but why? It would only use up disk space unnecessarily.

share|improve this answer
But there is also a number of symlinks in /bin, I guess that's one of the sources of confusion. Why sometimes executables would be symlinked and sometimes - hardlinked? – Dmitry Pashkevich Mar 1 '13 at 15:39
This answer fails to provide any reason at all for using hard links over soft links. – Mark Amery May 12 '15 at 18:30

There are any number of uses. I use them to create file-based locks. The link(2) system call is atomic, unlike most other system calls.

Another use is within rsnapshot, where backups are taken over time using hard-links to reduce the amount of disk space. If a file has not changed, then the file is hard-linked to the older instances of the file, files that have changed are copied anew.

I also use them to swap out config files on servers: rm file.cfg && ln ~/tmp/file.cfg file.cfg, then the ~/tmp/* files can be deleted safely.

share|improve this answer

To add to the several good discussions already present...

  • The way resource access for programs is implemented in unix (i.e. "everything is a file"), means that the infrastructure for handling multiple references to a file is required for the OS to work at all, so there is no added cost here.
  • The way directories were implemented in the original unix filesystems (i.e. a fixed format list of (inode, name) pairs means that there is no extra cost on in the filesystem to having hardlinks (well, as long as we prevent cycles by disallowing hardlinke to directories (other than . and .. (is this begin to feel like lisp to anyone else?)))

so we get them for free.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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