76

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

54

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.

  • 4
    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
  • 3
    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 '16 at 22:31
  • But hard links have a piece of info as well - their names. So it supposed to take space. – Josef Klimuk May 29 '18 at 9:48
37

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.

12

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.

  • 11
    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
  • 16
    This answer fails to provide any reason at all for using hard links over soft links. – Mark Amery May 12 '15 at 18:30
8

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.

  • Why the separate ln and rm instead of just a mv? – Tommiie Apr 1 at 5:34
6

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.

2

I should probably cover a pitfall scenario of hard links. A hard link will be just the same file with a different name and/or a different location as long as the original linked file exists. It's not even correct to think of the file as "original": both are directory entries in their own right, and both (or more) are all equal peers. For long-lived files, this may be a blessing, but if one of the pair is deleted and then created, even with the same name and contents, the files will separate.

Suppose you created a hardlink /foo/myfile linking to /repo/myfile. Both are pointers to the same file data; change one, the other changes. But suppose that /repo happens to hold a Git repository. If you check out a branch that does not contain myfile in it, /repo/myfile is deleted. At this moment, /foo/myfile becomes a simple copy of /repo/myfile, as it were at the moment the other of the pair was unlinked. It's easy not to even notice as you flip between branches that file repertoire changes, but, when you checkout the original branch, a new file /repo/myfile is created by Git. If you did not pay attention, you'd wonder why the two files now have different contents, although it is easy to grok, as the hard link relationship between the files has no idea about their names. A soft link, on the opposite, would survive through this delete-create cycle.

On the other hand, software that uses hard links is acutely aware of this, and Git is a prime example. Git clones a repository on the same filesystem for nearly free, because it uses hard links by default instead of copying files. For Git the hard link is a perfect use case, because its object and pack files never change, so one clone of the repository will never modify the other (Git knows not to hard-link modifiable files), and any of the clones can be deleted without any precaution: there is no need to track which one is the "original" and actually contain the files: any of hard links is an equal partner and "contains" the full file. Soft links just would not work here.

Another advantage of the hard link is that any link can be moved without breaking access to the file contents. With soft links, moving the original file renders all soft links to it dangling.

The bottom line is that in many use cases either link type works equally well, but in some one or the other type is advantageous. The efficiency, mentioned in many answers here, is probably of a very little concern with modern machines and filesystems, unless you are scavenging a filesystem on a FLASH chip of a puny embedded controller. The functional differences are more important, and usually dictate the engineering constraints and the ultimate choice:

  • The hard link "source" can be moved safely, while the soft link will break.
  • The hard link is indistinguishable from the file it was linked from, and the file is alive as long as any of the hard links is alive; the soft link is asymmetrical.
  • The hard-linked peer breaks out of the linked group if deleted and re-created, but the soft link does not lose its target.
  • The soft link may cross filesystems, the hard link cannot.
  • The soft link may point to a directory, the hard link usually cannot (and practically always should not).

Also, I must point that the library call that deletes a file is called unlink() for a reason! Every directory entry is just an initially singular hard link to its inode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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