When would creating a hard link be useful?

There are basically two main limitations with hard links:

1. Hard links normally require that the link and the file reside in the same file system.
2. Only the superuser can create a hard link to a directory.

Thus, symbolic links were introduced to get around the limitations of hard links. So, the question is, are hard links still needed? Might there be situation where they are more useful?

Solution 1:

Hardlinks help us organize our file system in a much more flexible way. Basically, hardlinks allow us to take one file and have it be in multiple places in the filesystem at once. Think about a scenario where you are a photographer and have lots of photos (this is an example from my life!). You might organize them by the people that appear in them, because sometimes people ask you for photos of them. But you might also want to organize them by the location and by the date. There's no real way to nest these three things as they're totally separate axes of organization. So you can create three different hierarchies for these three different things and have each photo present in all three, without having to store each photo three times. That's the magic of hardlinks. Unlike symlinks, we don't need to worry about where the "real file" is, because they're all the real file. We can delete and move at will because the file will be retained until there are no longer any references to it, and removed when you delete the last hardlink. It's simple and doesn't require you to keep track of very much.

Solution 2:

A file's contents will not be purged until all hard links (yes, all filenames are hard links, even the first) have been erased and the file closed. As such, it can be useful when a file is required in multiple places, but may be removed from any of them at any time, e.g. between ~/Downloads/coolsong.mp3 and ~/Music/Cool Song.mp3.

Solution 3:

One not very important advantage of a hard link over a symbolic link is that when it reaches the inode for a hard link, the kernel doesn't have any further processing to do to access the file. When it encounters a symbolic link, the kernel must read the link value and continue traversing the directory structure before it gets to the inode for the file. This takes longer, though the difference is not necessarily easily measured. It gets to be really fun when one of the elements on the symlink value is itself a symlink.