File links

- [Instructor] As we've been exploring the file system, 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 to take a look at the bin folder with a long listing. I'll scroll up a little bit. 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. A short cut, 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, I can see that the vim and vi commands that we used earlier aren't actually in the usr/bin directory. But they're off in the etc/alternatives directory instead. Where vi is really stored here isn't in my path, but because there's a link to it in a folder that is in my path, it works as I expect when I type a command name. There are two kinds of links, called hard links and soft links, or hard links, and symbolic links. To understand the difference, first we 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 disc in a series of data blocks. And the locations of those are stored in a structure called an inode. And then the file system associates the name of the file in its index of files with the data in that inode. When we create a link, we tell the file system to associate the file with a name we provide. A hard link associates that name with the inode of an existing file, and a soft link associates the name we provide with a file 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. 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 sym link shows up to the system as a short cut, or a reference to the referenced file. And a hard link shows up as a regular file. In fact, all the files you see in your file system, unless they are a soft link, are actually hard links themselves. Let's take a look at both ways of linking to a file. I'll clear the screen. Here in my home directory, I'll create a text file called users.txt and add some names. We've got five names here, and I'll write the file with control O and then exit nano with control X. And there's the file. Now, if I wanted to create a symbolic link for this, say I wanted to be able to access it from inside my documents directory, as well as from my home directory, I'd write ln for link, dash s, for symbolic, and then the full absolute path to the file. In this case, home, my user name, users.txt and then the destination documents, let's call it user dash list.txt. I'm using the full path here, because when sym links are interpreted, if they're set up with a relative path, for example just the file name for my user list here. The system will use the relative path wherever the sym link is. So with the relative path, the sym link would be pointing to users.txt inside of the documents folder, instead of in my home folder. I'll also make a hard link without the dash s option. I'll just write ln users.txt documents and let's call this one list.txt. And let's take a look at what this did for us. I'll write ls dash l documents to take a look inside the documents folder. Here I see my sym link, and a file called list.txt. The original file, here, and hard link file, here, both show up as taking the same amount of space, 65 bytes. And, in a manner of speaking, they do. But they take up the same 65 bytes, because they're referencing the same inode. So you could create, say, a thousand hard links to the same 1 megabyte file and it would look like you had 1,000 1 megabyte files, when in reality, only a megabyte of disc space would be taken up, not a gigabyte. I can use the cat command to print out the contents of the file. I'll write cat documents list for the hard linked file. There we go. And cat documents user list and I can see that both of these links allow us access to the contents of the original file. Using the command file, on my hard link, shows me that it's a file, an ASCII text file, just like the original one. And using file on the sym link shows me that that it's a symbolic link to the file with this absolute path in my home folder. Now, I'll rename my original file from users.txt to people.txt. And if I list the documents folder again, I can see here that my symbolic link's color has changed. And if I use file to take a look at that, now it shows as a broken symbolic link. So if I take a look at the contents of the symbolic link, with cat documents user list, I get 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, just its name. 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 the disc. I'll move the original file back to its original name. With mv people.txt users.txt. I'll list the documents directory again here, and we can see that our sym link is back to being not broken. And take a look at this column here, this second column with 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 linked file in the home folder, too. There's the 2 right there. If I delete a sym link 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 the references in the documents folder. I'll write rm documents list and documents user list.txt. And listing the home directory again, my original file is still here, but its reference count has changed to 1. File links and especially sym links are used as an organizational tool across Linux, so it's important to recognize them and know how to work with them.