CS 537 Notes, Section #25A: File System Links

OSTEP: Sections 39.14 and 39.15

Hard Links

As we have seen, a directory entry points to an inode. This connection between the directory entry and the inode is called a link or, more properly a hard link. Most file systems, including thoses on UNIX and Windows allow more than one directory entry to point to the same inode (or MFTE).

For example, suppose that we had a file name safefile.so in your personal directory /usr/bart/code, and you wanted the same file (not a copy) to also be accessible from the standard system library directory /lib as sf.so.

On UNIX, you could create another link to that directory with the "ln" command, which uses the "link" system call:

cd /lib/ ln /usr/bart/code/safefile.so sf.so

In the this figure, we can see that we created (in green) another path to file safefile.so but with the new name /lib/libsf.so.

Note that the file access permissions for safefile.so and sf.so are the same because they are the same file. However, the permissions on the directories that lead to each of these names for the file could be different.

Also note that if you modify the contents file, then any use of the file from either path name will see the change.

When you remove one of the file name, you just remove that link to the file. That's why the remove system call on UNIX is called "unlink". The file will actually be removed when all links to the file are removed, i.e., the file's link count goes to zero. In our example, if you removed the file from /lib and then replaced it with a new version, then your local directory would still point to the old version of the file. Think about this case carefully.

Interesting fact: the "." and ".." file name entries in each directory are just hard links to the same directory and parent directory, respectively.

Symbolic Links

As we saw above, it can be complicated updating software when you are using hard links. Also, hard links cannot point to files on another disk. And in the Windows operating system (as we will see in the next section, hard links can make certain operations on the file system expense. For these reasons, and a variety of others, operating system designers developed another kind of link called a symbolic link or soft link.

The idea of a symbolic link is that directory entry for a file does not point to an inode; instead it contains the name of a file.

For example, we can create a file named safefile.so in directory /usr/bart/bart/code (shown in red in the figure below), and this file will point to /lib/sf.so:

cd /usr/bart/code ln -s /lib/sf.so safefile.so

When you open file /usr/bart/bart/code/safefile.so, the file system reaches the directory entry for safefile.so and sees that it is a symbolic link. It then takes the file name stored in that entry (/lib/libsf.so) and then opens that file.

Note that in our symbolic link example, if you removed /usr/bart/bart/code/safefile.so, only the directory entry for /usr/bart/bart/code/safefile.so would be removed. The file and directory entry for /lib/libsf.so would remain unchanged.

Now, if you removed file /lib/libsf.so, the symbolic link would remain unchanged. However, if you then tried to open file /usr/bart/bart/code/safefile.so, you would get a "file not found" error because /usr/bart/bart/code/safefile.so pointed to a file that does not currently exist.

If you then created a new /lib/libsf.so and tried to open /usr/bart/bart/code/safefile.so, then the open would succeed and you would be pointing to the new version of /lib/libsf.so. Again, think about this case carefully.