What is the link

If you come from the MS Windows world, think a link as a "shortcut" you created on the desktop.

If you are not, well, a link gives an easy access to a file or directory from somewhere other than its location, and is a way to help you organize your files.

For example, if you find your friends Tom has a good script coool in his ~tom/bin directory, and you want to run it often. What can you do?

• You can copy his script to your ~/bin directory, thus you don't need to type ~tom/bin/coool every time. However, if Tom updates his script and add some new feature, you won't be updated.
• You can add ~tom/bin to your $PATH. This way you can always use Tom's newest version. However, you must be very careful about where to put "~tom/bin" in your $PATH. In the beginning? What if he has a "rm" script that you don't want? In the end? What if there is already another runnable called "coool" in your $PATH? And in the middle? Well, maybe you can by-pass the problems of both, or maybe you'll have both of the problems.
• Write another script that calls Tom's script. Needless to say, this requires some shell programming skills from you. And even you do, you'll know that this will start up two shell processes, thus waste some resources, and be slower.

If this is your situation, a link from your ~/bin directory to Tom's ~tom/bin/coool is the best solution. This way you can call it as if it is your script, and you'll benefit from the new version from Tom as soon as he makes any changes.

 

 

The Linux file system basics

To understand how link works on Linux, we'll need to dig more into the file system.

In the last article, I've said a directory in Linux is just a special type of file, with blocks of infos about files and sub-directories under it. Actually, it's more complicated than that.

In the blocks of the special "directory file", there are at least two things:

• The name of the current record, which is the name of the file or sub-directory.
• The inode of the file or sub-directory.

Wait... But what is an "inode"? An inode is a data structure used in the Linux file system. They are unique on one file system. In it we can find the infomation about where to find the data of a file. That is, the physical location on the disk of a file, and many other things.

 

 

How hard link works

For a hard link. The two inodes pointed to in the two blocks of the two different "directory file", are actually the same one.

Let's do some experiment to make this clear. First, let's setup our environment:

$ mkdir directory1
$ mkdir directory2
$ cd directory1
$ touch file1

Now let's do some check:

$ ls -l
total 0
-rw-r--r--   1 ddliu    ddliu    0  7 24 17:57 file1

Now let's make a hard link from directory2:

$ cd ../directory2
$ ln ../directory1/file1 file2

and do another check:

$ cd ..
$ ls -l directory1/file1
-rw-r--r--   2 ddliu    ddliu       0  7 24 17:57 directory1/file1
$ ls -l directory2/file2
-rw-r--r--   2 ddliu    ddliu       0  7 24 17:57 directory2/file2

The -i option of the ls command will give the inode number of a file:

$ ls -i directory1/file1
16274483 directory1/file1
$ ls -i directory2/file2
16274483 directory2/file2

As you can see here, the inode number of file1 and file2 are the same.

Good. But what does this mean? This means, although the two files have different names, and in different directories, they share the same content, and are on the same physical location on the disk. If you edit one of them, the other will be changed immediately.

And what if I delete one of them? Good question! If you are sharp, you'll notice something in the output of the two ls -l command above. There's something changed: Just after the permission field, we got a 1 in the first run, and got a 2 in the second run. This is a counter number in the inode.

The inode keeps a counter about how many times it is referenced in the file system. So if we do a hard link, the number grows by one. And if we delete a file, the number becomes one less. The real file content will only be erased, and the disk space will only become available for other files, when the counter gets to zero. (Actually the inode also holds how many processes are opening this file, and only erase the content when this counter is zero, too. But this beyonds the scope of this article)

So, in the example above, if we delete file1, file2 will still be available. Even though file2 is a link to file1. Actually, Linux don't know which file is the source, and which is the link, after the hard link is done.

 

 

How soft links works

OK, all the hard link things are cool. However, there is one limitation: You can only link to a file that is on the same file system. For example, on most systems, /usr and /home will be on two different file systems. So if you try to do something like:

$ ln /usr/local/bin/vim vi

You'll get an error message like:

Adding new name: cross-device link, /usr/local/bin/vim, /home/ddliu/bin/vi

As we talked above, the hard link works by pointing two file infos to the same inode. And the inode info is unique on one file system. If Linux allows us to make hard link cross file systems, it will be not able to find out which file system should it find the inode later.

To make a link cross file systems, we'll need a soft link, or symbolic link, using the -s option of ln:

$ ln -s /usr/local/bin/vim vi

And let's do some check, to make things clear:

$ ls -l
total 0
lrwxr-xr-x   1 ddliu    ddliu    18  7 24 19:16 vi -> /usr/local/bin/vim

Note the first letter is l, as we talked in article Linux File permissions: Beyond "rwx", we know this is a symbolic link file. The inode counter is 1. And this file is quite small: only 18 bytes. At the end, instead of printing out the file name, ls printed vi -> /usr/local/bin/vim, the name of the link file we made, and where it is linked to.:

$ ls -i
16180337 vi
$ ls -i /usr/local/bin/vim
4882702 /usr/local/bin/vim

As expected, the link and its source have different inode numbers. Note this is not necessary: in a very rare case, they may have the same inode number, but -- that will be just an coincidence. Those are inodes on different file systems, thus pointed to different location on the physical disk.:

$ ls -l /usr/local/bin/vim
-rwxr-xr-x   1 root     wheel    1603996  6 30 08:32 /usr/local/bin/vim

OK, the source file is much larger than the link we made. And have different owner and group owner. The source and the link are actually two different files.

So how does symbolic link work? If you count the length of "/usr/local/bin/vim", you'll find it's 18 characters. Which needs 18 bytes to store, and which is exactly the size of the link file we made: 18 bytes. This gives a good clue of how soft link works:

The soft link is a standalone file, which has its own inode. The inode point to a physical section on the disk, which holds the content of our link file. And the content is, the full path, "/usr/local/bin/vim" in this case, of the source file.

When you try to access a symbolic file, the system will first find the block of this file in the "directory file", then find the inode of this link file, and find out the content of this link file -- the full path of the source file. Then the system will check the block of the source file in its parent directory's "directory file", find its inode, and finally find the content.

So, if you edit a symbolic file, or its source file, the changes will be available on the other side. However, the source file knows nothing about the link file. If you delete the link file, only the inode and disk space related to this link file is freed. But if you delete the source file, as the system don't know how to find the files symbolic linked to it, the link file will NOT be noticed. If you try to access the link file after its source deleted, you'll get an error message like:

Opening input file: no such file or directory

 

 

pros and cons of each

So, if the source file and desk file are on the same file system, hard link is a better choice most of the time, because:

• It is faster, because it only need to read one inode to find the file content , and a symbolic link will need to read two different inodes.
• It use less disk space, cause we won't need a block on the disk to store the full path of the source file.
• If the source is deleted, we still have a copy.

Symbolic link has some advantages over hard link, too:

• It works cross file systems, sometimes it is our only choice.

• It is auto updated if the source is updated.

  This may need some more explanation.

  Think the vi/vim example above, assuming we can make a hard link there. What happens if /usr/local/bin/bim get updated from version 6.0 to 7.0? For a hard link, the link file will hold the old binary, and all its contents. So when you run vi, you runs vim 6.0. But for a soft link, as the link file only holds the path to the VIM binary, you got vim 7.0 when you run vi.

  The key here is, for a program upgrade, we usually delete the old version first, and then install a new version. Thus the old an new /usr/local/bin/vim will have different inode number, though the same file name.

           

dryice at dryice dot name

 This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
                

This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License.