The beauty of hard links

flickr/neurmadic aesthetic

I am often surprised by how little use my fellow Unix admins make of hard links. It may be because their presence in our file systems is so much more subtle than their soft (i.e., symbolic) link cousins, but if you like the idea of a file just showing up in a second location without the overhead of additional disk space, hard links are very effective. A hard link is, basically, another instance of a file -- not a copy and not a reference (as is a soft link), but another appearance of a file. It can be in the same directory with a different name or somewhere else in the file system by the same or a different name. If you pull that off as a person, it would like being in two places at the same time. I often wish that I could do that myself!

[How to freeze Unix accounts and 13 Things that a Unix sysadmin will never do]

The way to create a hard link is to use the ln command, but without the -s command that is used to create symbolic links. The way to recognize a hard link is to look at the second field in a long file listing. If it's a "1", the file has no hard links. If it's 2 or greater (and not a directory), the same file exists somewhere else in the file system. If I have a list of my favorite beers, I can create a hard link to the file very easily. First, I list the file:

$ ls -l
total 24
-rw-r----- 1 shs dweebs 11320 Jan 27 15:42 beerlist

Then I create the hard link just to demonstrate that I can:

$ ln beerlist beers
$ ls -l
total 24
-rw-r----- 2 shs dweebs 11320 Jan 27 15:42 beerlist
-rw-r----- 2 shs dweebs 11320 Jan 27 15:42 beers

When I use either file, I get same result, of course, since they're really the same file in everything but name.

$ wc -l *
  485 beerlist
  485 beers
  970 total

When we create a hard link, notice how the "links" field now shows up as "2". This would be the case no matter where in the file system we created the link, of course. It's just easier to see when the files are next to each other. The listing above with the "2" in each link wouldn't tell someone who just landed in this directory that these two files are hard links of each other. They might notice that the two files are the same size and that the date and time associated with the two files match, but that wouldn't necessarily guarantee that the files are hard links to each other. The real test is to use the ls -li command. This command will show the inode for each of the two files. If the inodes match, then the files really are hard links, sharing disk space and the inode structure which houses their metadata (owner, permissions, etc.). When you make changes to a hard link, both the original file and the "link" are changed because there's really no difference between the two except for where they show up in your file listings and what you call them. OK, so what is the real beauty of hard links? It's not the second field that excites me, but the fact that the additional file takes no additional disk space -- aside from the reference in the directory file in any case. The most convenient access to a large file is often to create a hard link in a convenient directory. You can then access and even edit the file without having to cd your way to another directory or even remember where the original file is located. In fact, the only downside to hard links is that they can only reside in the same file system as the original file.

$ ls -li
total 24
12763161 -rw-r----- 2 shs dweebs 11320 Jan 27 15:42 beerlist
12763161 -rw-r----- 2 shs dweebs 11320 Jan 27 15:42 beers

If we had a third hard link and then looked for all hard links using the inode number, we might see something like this:

$ find . -inum 12763161 -ls
12763161   12 -rw-r-----   3 shs      dweebs     11320 Jan 27 15:42 ./beerlist
12763161   12 -rw-r-----   3 shs      dweebs     11320 Jan 27 15:42 ./hlinks/beers
12763161   12 -rw-r-----   3 shs      dweebs     11320 Jan 27 15:42 ./hlinks/beerlist

Does it matter which link was created first? Not one bit. Once a hard link is created, it and the original file are no different except that they have different file names, sit in different directories or both. The advantages of symbolic links are that they can exist anywhere on a system (they are NOT restricted to living in the same file system) and that they are pretty obvious with the link -> file in their listings. Plus symbolic links also take very little room in the file system. The files are only as big as the names of the files they point to. But when you remove a hard link, the other file or files remain intact; only the link count goes down. When you remove a symbolic link, it makes a big difference whether you remove the link or the file the link points to. Symbolic links, therefore, can "break". That is, you can remove a file and fail to remove the symbolic links that point to it. You can also create symbolic link which points to a symbolic link that points back at the original file. Whether directly or through a series of links, you'll end up with the "Too many levels of symbolic links" problem. This won't ever happen with hard links. The only problems with hard links is that it's takes extra steps if you want to determine where the original file sits in the file system and having to remember what that second field in a long listing is telling you. That's not bad for a really useful feature in our favorite OS.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT