Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
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
add comment

migrated from stackoverflow.com May 25 '11 at 7:46

This question came from our site for professional and enthusiast programmers.

5 Answers

up vote 6 down vote accepted

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.

share|improve this answer
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
add comment

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.

share|improve this answer
    
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 at 1:24
add comment

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.

share|improve this answer
    
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
add comment

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)

share|improve this answer
add comment

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.

share|improve this answer
    
Sounds like rsnapshot. –  Ignacio Vazquez-Abrams Jun 22 '11 at 10:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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