There are basically two main limitations with hard links:
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?
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.
gzip, gunzip, and zcat.
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.
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.
there are several reasons for hard-links
So one reason to use hard-links is to possibly save lots of space ...
You can append to either of the references and the data goes into the shared file. You can also append to one file descriptor while reading from the other (e.g. with tail -f)
One useful case is, say, when you have a program (or script) which needs to download a large temporary tarball and after extracting it your program will delete it immediately.
If you for some reason want to preserve that tarball for future use, the best way ls to ln /tmp/tarball.tgz ~ while the tarball is still being downloaded. Then you don't need to do anything.
When the download finishes, and even after your program deleted the 'original' one, the exact copy should still be in your home directory.
Many of the examples given here are valid, but would work equally well with soft links (e.g. the "need one file in multiple places" problem).
A nice example for where hard links are really helpful is the backup software Dirvish:
Dirvish is a fast, disk based, rotating network backup system.
With dirvish you can maintain a set of complete images of your filesystems with unattended creation and expiration. A dirvish backup vault is like a time machine for your data.
Dirvish creates backups at the filesystem level (i.e. it copies files, it does not create images), by copying files to a separate (backup) filesystem (such as an USB harddisk). Each time you make a backup, dirvish will create a separate, complete copy of the directory tree to be saved.
The trick is that if dirvish detects that there is already an older backup copy of the tree you are saving, it will automatically reuse files that have not changed, by creating a hard link in the new tree to the file in the old tree.
That way, each backup copy is a complete, self-contained copy of the directory tree, but at the same time only the changed files actually take up space in the file system. In other words, you get the benefits of incremental backups (space savings) and full backups (easy retrieval) at the same time.
This is only possible because hard links are completely transparent to userspace tools.
This would probably also work with symbolic links (although you'd get problems when backing up data which uses symbolic links itself), but one advantage only possible with hard links is:
If you want to throw away old backups, you can simply delete the corresponding backup directory tree. Files only linked from that tree are deleted automatically by the filesystem (because their last hard link is deleted), but files that also appear in other copies remain on disk.
I use 'Hard Links' to backup some of my 'HowTos' and Snippets
I have a directory named 'Shared Docs' in my user/root. In that directory I have 'hard links' to my tips, tricks, snippets, howto's which live in their appropriate directories; php, mysql, css, regex, formulas, linux, etc., Having them in 'one place' makes it Much easier to use, update them than having to jump around in my Documents/ directories looking for these documents I use often.
Long ago, I used symlinks. I would faithfully backup up this common 'Shared Docs' directory to my server. Problem is, symlinks or 'Soft Links', if copied (cp -auv) or tar'ed and copied off, ONLY backup or copy the 'link' and NOT the content of the document. So, I'd have to traverse the directories and copy off each of 2 dozen files from their actual location.
With HARD LINKS, I can copy off, tar, rsync the 'Shared Docs' directory and Actually backup those widely dispersed documents with confidence, the content is actually backed up. It's really sucked for me, when I realized I'd been backing up 0 bite 'link files' and Not the information.
Downside to using 'Hard Links' is that doing ls on a directory does not give you an indication that a file is 'linked' with another file or where that file may co-exist. There are ways to find them, but I'm saying it's not obvious with a simple ls -l --> points to... So, I usually add a note to the beginning of the document indicating what directory/files 'this file' is 'shared' with
Landis.
