Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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

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?

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.

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.

Quote:

Originally Posted by PTrenholme

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?

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.

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?

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 ... :|

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.

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.