Why use hard links?
 

I understand why you want to use links. It saves time and space. But it seems like you would always want to use symbolic links. They overcome all the limitations that hard links have. So what do hard links have that soft links don't?

If you remove the file a soft link points to the soft link will be broken and not work anymore. This doesn't happen with a hard link, the file will still be accessible through the link. Only if any hard link pointing to a file (in fact pointing to an inode) is removed the file (in fact the inode) will be removed.

You can also rename either branch of the hard link without breaking anything.

With a hard link, the link points to the inode directly. With a symbolic link, the link points to the object (which then in-turn points to the inode). Hard links are a way of bypassing the middle-man, it's like creating a copy of the original file, while only using the disk space of one file.

That said, I almost never use them. They do have their advantages though.

hard links are like copies and soft links are like shortvuts.why do want to use either of them ?

Because they are useful. Simple answer.

I don't have any application in mind, I'm just trying to understand it.

A symbolic link can span file systems or reference directories, which a hard link can't do.

A hard link can reference deleted files, but I can't think of a reason why you would want this behavior.

In other words, a symbolic link seems more desirable in all circumstances. Why use a hard link instead of a symbolic link then?

Hard links are useful for backups. It allows you to make a "copy" of the file, without actually copying the file. For example, say you have a very important, very large set of data, multiple people have access to it and use it regularly. Now you want to make a backup of this data, just in case some nimrod deletes something or renames the directory and breaks your system, however you can't afford to actually copy the data (say it's 20TB), what do you do?

A symbolic link is useless, but a hard link will allow you to make a "backup" of the data elsewhere on the filesystem, without using any additional disk space. If some user accidentally moves, renames, or deletes one of these critical files, it disappears from the primary location, but the backup location still works, so you can just hard link it back into where it's supposed to go, no worse for the wear. If you want to actually delete the file, you just delete it in both the primary and backup locations.

The Mac timemachine backup system uses hard links like they're going out of style. Quite the surprise when the backup drive only contains 100GB of data, but when you cp it onto another machine (without setting the necessary hard link flags) it explodes into a terabyte or more.

It is not only about deletion of files. Hard links can make your life much easier when moving files. Imagine you have a file and 10 soft-links pointing to it. If you now move the file all the soft-links will be broken and you have to adapt all of them. That isn't necessary with hard-links, they still would be working.

EDIT: suicidaleggroll was faster.

Thats a great explanation. Thanks

Ah so! Is that what's happening when btrfs or LVM creates a "snapshot?" I did wonder why the snapshot was so small.

Of course, since the hard link is "pointing to" the inode, that inode remains in the active storage, using space on the drive(s), even when the link target is no longer needed. Is there some easy way to find all the hard links to some object so the space used by the object can be released when you really want to delete it?

That is correct. Every inode keeps track of the number of hard links pointing to it. Any time you create any file, this number is initialized to 1. Whenever you add a hard link to the same inode, that number will increment by 1. The file is only considered "erased" when the number of hard links to it drops to 0.

I don't know if there's a faster way, but you can use find to locate any other files on the filesystem that point to the same inode as the file you're interested in (aka: hard links to the file you want to delete). There probably is a way to print out the actual path/filename for any hard links pointing to a given inode without having to use find to search the entire filesystem, but I don't know what it is.

Of course, thinking of a hard link as a back-up is a tad dangerous if the nimrod
doesn't move or delete a file, but modifies its content ... :|

True, it only protects against deletion, not modification.

If you wanted to get fancy, you could implement a versioned backup system using hard links though. Copy the original directory into a dated backup directory. From then on you create a new dated backup directory and start cycling through the files to be backed up. Any file that has been added or differs from the version in the previous backup, you copy into the current backup, any file that's the same you just hardlink from the previous backup. That way all of your dated backup directories contain every backed up file, but only take up the hard drive space of the files that changed since the last backup. You could do the same thing with soft links, however with hard links you could go back and clean up old backups, without worrying about deleting the target from your newer backups for any files that haven't changed in a while. The file will only actually be deleted when all backups that reference it have been deleted.

If you're interested in incremental back ups with rsync (using hard links) the basic operation is:
Have a look at http://www.mikerubel.org/computers/rsync_snapshots/ for some more detailed info.

music collection
 

I'm using hardlinks for music playlists..
my NAS stores entire albums for artists, then I hardlink my favorite tracks into another directory to create a sort of playlist.
Then I share that directory out to other devices multiple ways; CIFS, Plex Media Server (with DLNA enabled for PS3 / XBox360), Logitech Media Server (for whole house song syncing).
This saves space instead of having multiple copies, the con is, it takes a while to build the library at first... but it's worth the space savings to me.