Why do hard links exist?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 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.

Answer 7

Symlinks are very brittle. If any element within whatever path you use as the target changes, it will break. This might be caused by renaming the original file, moving it, or renaming any of its parent directories.

In contrast, a hard link will survive any of those actions, although it comes with its own gotchas — software that copies and moves files instead of writing to them, without checking if there are multiple hard links, will break the connection.