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?

  • 3
    1) Symlinks aren't followed by some HTTP servers 2) Hard links can be used for backups 3) You can share unix sockets between chroots 4) You can delete any version of a hard link without affecting the others – Dietrich Epp May 25 '11 at 5:21
  • Can those HTTP servers use a hardlink that points to a symlink? , or Am I talking nonsense? – arana Jan 11 '18 at 21:26

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 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, 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. Unlink 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.

  • 1
    Or one might have one program that one wants to invoke by the three names gzip, gunzip, and zcat. – JdeBP May 25 '11 at 10:12

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.

  • 3
    That's correct. I use it to keep seeding a torrent while having the correctly named file in my clean movie folder. It's far easier than moving and renaming files that are being seeded, and I can simply delete the torrent folder when I am done seeding. That's also how Couch Potato does it. – Nicolas Bouliane Jan 30 '14 at 1:24

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.

  • Excellent point. In Solaris, one could create loops using symlinks, the processing of which is even more fun :-) – Anonymous May 25 '11 at 5:33

there are several reasons for hard-links

  1. to keep references to a file until the last reference is gone (as Ignacio pointed out)
  2. when you hard-link files, they only take up the space of one file in the file system (both references to the file share the same i-nodes). Therefore hard-links have to be on the same file system.

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)


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.


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.


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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.