Use cases for hardlinks?

Hard links are useful for cases where you don't want to tie the existence of both files. Consider this:

touch a
ln -s a b
rm a

Now b is useless. (And these steps may happen quite far apart, be done by different people, etc.)

Whereas with a hard link,

touch a
ln a b
rm a

b is still present and correct.

A single program may change its behavior depending on what name it is launched as:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Which over in the source is decided via something like

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

though the exact details wil vary depending on the OS and language involved.

This allows (mostly) identical code to not have to be compiled out to two (mostly) identical binaries. Bear in mind unix dates to days when disk space was super expensive, though according to Stevens in APUE chapter 4 symlinks were implemented in BSD4.2 (1983) to replace various limitations of hardlinks. A test program to check whether the symlink name is used as the program name might look something like:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

And tested via:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Filesystems are a simple and yet an efficient way to organize and classify files (this is its very primary reason for existence). Hardlinks allow a higher degree of flexibility in this matter.

As mentioned, there is no concept of original and copies when dealing with hardlinks, all directory entries (hardlinks) are simply references to the existence of the file (point to its inode) with no precedence, hence there are also no broken hardlinks...

So here there are some of the use cases that hardlinks attend but softlinks don't:

1. Imagine you have a collection of movies or music or other media and want to have different classification criteria applied, like songs classified by artist in a branch (each artist has its own sub-directory); by genre in another branch (each in a different sub-directory), etc.. Still you don't want to duplicate the files nor to decide where to put the "original" so that you have the freedom to reclassify without having to "manage" and re-link files when moving in order to avoid broken links.

2. Another reason is to avoid the waste of storage space that would be required for having multiple copies of the same file and yet allow the chroot syscall to benefit from a subset of files in the "master" filesystem root (symbolic links could never reference files from outside the chroot sandbox, even if they have relative paths).

3. Another very important but rarely mentioned reason for hardlinks to exist are the .. subdirectories. The .. directories actually are (in most unix fs implementations) hardlinks to the parent directory, without hardlinks this has to be implemented in a completely different way, while the existence of hardlinks makes this very easy to be implemented.

I had recently a use case for a somewhat safe update procedure for U-Boot based systems where uImage is a soft-link pointing to the image to boot, the idea was that a power outage should pose no problems, no matter at which point in the process it happens (assuming the file system plays along):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Without hardlinks it wouldn't be that simple.

When my P2P software finishes downloading a certain file, the file is placed in a specific directory. Downloaded files hardly ever need to be edited. The common case is I make a hardlink in a different directory where I need the file to be.

Advantages:

• I still share the file in P2P network as I should even if I 'rm' or mv the "copy".
• The file is also at the path where I need it; most of such locations are not shared.
• I can rm the "original" to stop sharing the file; this operation doesn't affect the "copy" in desired place.
• My diskspace is used just once.

The main point: if I knew in advance which file I would rm first, I might go with symlink. But I never know.

Very common, real-world example that needs hardlinks:

git clone --reference <repository>

This clones from an local Git repo with nearly zero copying. Instead of copying the object files (immutable files used by Git for its "database"), it simply hardlinks them.

Any repo can remove an object, but the inode stays valid for the rest of the repos. And if an object is removed from all repos, it's deleted from disk. Hard links make for a beautifully robust and fast solution. Very common in CI servers.

There is a non-hard-link version: git clone --shared <repository>. This, however, has a lot of caveats since everyone is working on the same directory.

BackupPC is a backup system that uses hard links on the servers to provide file-level deduplication.

Hard links are superior to soft links here because they provide automatic reference counting. Files are first stored in a "pool" directory tree based on their md5 hash. Any backup that makes use of that file makes a hard link to the pool file. As backups expire or are deleted, their hard links are removed from the filesystem.

A cron job periodically deletes any files in the pool directory that don't have more than one link.

This method has some disadvantages (principally, that it is difficult to use filesystem-based tools to replicate the backup store), but it's proven to be quite robust in practice.

Another use case: the tomcat java web application server treats file names as metadata (a java "war" file must be named based on its path on the web server).

e.g.: foo.war is the java code that serves the url /foo

Unfortunately, it resolves symlinks before making this decision.

So, say you want to deploy an application build, and give it a descriptive file name (e.g., with a release number or date). You can't make a symlink to the file with the "real" name - you have to make a hardlink.

foo.war symlinked to foo-20170129.war doesn't work

foo.war hardlinked to foo-20170129.war does work.

i don't like this tomcat behavior, but hardlinks give me a way around it.

One use that I have had for hard links is when downloading or uncompressing a broken file. The program that does the downloading or uncompressing (such as unzip or unrar) will often automatically remove the incomplete file when it encounters an error, and there is usually no option to keep it. If I want to keep the file, I can make a hard link to it.