From the course: Ubuntu Linux: Essential Commands and System Administration

Hard links and symbolic links

From the course: Ubuntu Linux: Essential Commands and System Administration

Start my 1-month free trial Buy for my team

Hard links and symbolic links

“

As we've been exploring the filesystem, there's one type of file that I haven't been mentioning much, and I want to cover that now. I'll write ls -l /usr/bin. And we'll take a look at the Bin folder with a long listing. These items that start with l, the links, are an important feature of working with files on Linux. A link is a reference to a file in a different place, like a shortcut in a manner of speaking. They allow us to expect to find a certain file at a certain path, even if that other file is really located somewhere else. So here at the end of this list, I can see that this command and this command are both actually links to this command here, which we can find right there. There are two kinds of links: one kind are called hard links, and the other kind are called soft links or symbolic links. To understand the difference, we first need to understand a little bit about how file information is stored and referenced. When I have a file, say, users. txt, the actual data in the file is stored on the disk in a series of data blocks, and the locations of those are stored in a structure called an inode. When we request data using a file name, the filesystem associates the name of that file with the data in the inode. When we create a link, we tell the filesystem to associate a file with the name we provide. A hard link associates a name with the inode of a file, and a soft link associates the name with the name of an existing file. So if we make a hard link to users. txt and then rename users. txt, our link will still point to the same information on the disk. But if we make a soft link to users. txt and then rename users. txt, our soft or symbolic link will break. Because of how they work, a symbolic link or a symlink shows up to the system as a shortcut or a reference to the referenced file, and a hard link shows up as a regular file. In fact, all of the files you see in your filesystem, unless they're a soft link, are actually hard links themselves. Let's take a look at both ways of linking to a file. Here in my Home directory, I'll create a text file called users. txt, and I'll add some names. I'll save this with Ctrl O and exit with Ctrl X. There's my file. If I wanted to create a symbolic link for this, say I wanted to be able to access the same information from inside my Documents directory as well as from my Home directory, I'd write ln for link, -s for symbolic, and then the full absolute path to the file, in this case, home, my username, users.txt, and then the destination: Documents, and let's call it userlist.txt. I'm using the full path here because when symlinks are interpreted, if they're set up with a relative path, the system will use the relative path starting from wherever the symlink is. So with a relative path, the symlink would be pointing to users. txt inside of the Documents folder instead of inside of my Home folder. I'll also make a hard link without the -s option. I'll write ln users.txt into Documents, and let's call that one list.txt. And let's take a look at what this did for us. I'll write ls -l Documents to take a look inside the Documents folder. Here I see my symlink and a file called list.txt. My original file and my hard link both show up as taking the same amount of space, 64 bytes. And in a manner of speaking, they do both take up 64 bytes, but they take up the same 64 bytes because they're referencing the same inode. So you could create, say, 1,000 hard links to the same one-megabyte file, and it would look like you had 1,000 one-megabyte files when, in reality, only a megabyte of disk space would be taken up, not a gigabyte. I can use cat to print out the contents of the file. I'll write cat Documents/list.txt for the hard link. There we go. And cat Documents/userlist. And I can see that both of these links allow us to access the contents of the original file. Using the command file on my hard link with file Documents/list. txt shows me that it's a file, an ASCII text file, just like the original one. And using file on my symlink with file Documents/userlist. txt shows me that it's a symbolic link to the file with this absolute path in my Home folder. Now here in my Home directory, I'll rename my original file from users.txt to people.txt with mv users.txt people.txt. And if I list my Documents directory again with ls -l Documents, I can see that my symbolic link color has changed. If I check that out with file again, I can see that it shows as a broken symbolic link. So if I take a look at the contents of the symbolic link with cat Documents/userlist.txt, I get a "No such file or directory." But if I take a look at the contents of the hard link file called list, I can still access the information because the original file's inode hasn't changed; only its name has changed. In fact, we can't really even say which is the "real file" with a hard link because both files we see are just references to the actual data on disk. I'll move the original file back to its original name with mv people.txt users.txt. I'll list the Documents directory here again, and we can see that our symlink is back to not being broken. Take a look at this column here, the second one from the left. It has some numbers in it. This indicates how many hard links a file has to it, or rather how many hard links exist that point to the inode that this file points to. That number will be the same for this hard link file in the Home folder too. Here I can see list has two links, and over here, users also has two links. If I delete a symlink or a hard link, it doesn't remove or affect the referenced file at all, unless the file is the last hard link to an inode. I'll delete both of the references in the Documents folder. I'll type rm Documents/list.txt and Documents/userlist.txt. And listing the Home directory again, my original file is still here, but its reference count has changed to one. Hard links and symlinks are used extensively on Linux systems, so it's important to recognize them and know how to work with them.

Contents