This is a LinuxChix course page. This and the other courses pages are yet to be ported to the new LinuxChix website. Please feel free to browse the course in the meantime.

We appreciate your patience.

The UNIX Filesystem: Lesson 2 supplement

Introduction

When I initially posted Lesson 2, I got a lot of feedback requesting an explanation of how symbolic links actually worked. I was intending to cover this at a later stage, but decided that it could be handled now without losing too many of you. If you don't particularly need/want to know how symbolic links are actually implemented, and are content just using them, that's fine. If you stop reading right here and wait for Lesson 3, you won't lose out. This is just a digression for those who are interested, and isn't necessary to understand the rest of the course.

Q. What is a symbolic link?

A symbolic link is a file (or directory) which behaves to all intents and purposes like its target - the file or directory to which it points. For example, if I have a symlink called /home/meredydd, pointing to the directory /export/meredydd/, then the path /home/meredydd will start acting exactly like the path /export/meredydd/. You can list its contents, read and write files in there, everything you can do to a normal directory. But it's not. What you would actually be doing is manipulating /export/meredydd/.

Q. How does it work?

Oh. Now there's a question, and one that can be answered on many levels. Because this is a basic course, I'm going to go only so far in answering it. If you're interested in further implementation details, you can ask on the list and I will attempt to rustle up some links for you. Failing that, Google is your friend. But anyway...

A symbolic link can be thought of as a small, very special file, containing just one string - the target path. That's all it is. For example, the symbolic link I created in the Lesson 2 demonstration is just a file, marked specially as a symbolic link, containing the string "/home/meredydd/web/". Whenever the kernel (that's the part of the operating system which handles things like file accesses, networking, etc for programs - we'll see a lot of it in Lesson 3) gets asked to do something to the link, for example list the contents of the directory /home/meredydd/backups/web/, it reads the file, finds that it's a symbolic link, and retries the same request on the target path (/home/meredydd/web/). This time, it hits an ordinary directory, and so lists its contents in the normal way.

This, by the way, is the real reason for the odd behaviour of ../ in symlinks (see the green box in Lesson 2). In my example, we now see what's going on - when ls asks the kernel to list the contents of backups/web/../, the kernel realises that backups/web is a symbolic link, and so converts the path to /home/meredydd/web/../, with predicatable results.

Q. What do you mean by "Symbolic links are relative"?

Simply that - the target of the symbolic link is a relative path. This is explained by the way that the operating system's kernel handles any request made of a symbolic link. For example, if I have a symlink called /usr/X11, with a target of "X11R6/", and try to list the contents of /usr/X11/, the process I described in the previous paragraph occurs. The kernel notices that /usr/X11 is a link, and substitutes the target path for the one that was originally requested. Here, however, there is a difference. The target path is not absolute (it does not begin with a /). So, instead of replacing the original path entirely with the target, and trying again, the kernel backs up to the directory containing the symlink (in this case, /usr/), appends the new relative path, and then tries again. So /usr/X11/ becomes /usr/X11R6/. Very well and good.

You can also, however, use the ../ element in your path, which is when things get slightly unintuitive. If, for example, the sample symlink I created in Lesson 2 had ../web/ as a target (rather than the absolute path /home/meredydd/web/), it still would have worked. The reason? When accessing the path /home/meredydd/backups/web/, the kernel would realise that it was looking at a symlink, and do the normal thing - take the directory containing the symlink (/home/meredydd/backups/), and add on the link's target, producing /home/meredydd/backups/../web/, which would work perfectly.

Demonstration

The important thing to grasp is that the string you give to the ln command is not interpreted at all. It just gets written into the symlink - it is only when you access that link that the string is taken any notice of. This means that if you move a symbolic link around, but leave its target the same (which is what happens if you move or rename it - you don't expect the contents of other files to change when you move them, do you?), you can change what it points to.

Try this:

meredydd@rhodium:~$ mkdir tmp/
meredydd@rhodium:~$ ln -s ../ tmp/parent_dir
meredydd@rhodium:~$ ls -l tmp/parent_dir/

This will list the contents of your home directory. Why? The symbolic link parent_dir has a target of ../, so in fact you are listing the contents of the directory tmp/../ - your home directory. Now try this:

meredydd@rhodium:~$ mv tmp/parent_dir ./
meredydd@rhodium:~$ ls -l parent_dir/

You will now see the contents of ../ - in this case, the directory /home/.

Q. What's a "hard link", then?

A hard link is where two paths (specifically, two files - it doesn't work for directories) refer to the same data on a volume. They can also be created with the ln command, but are very rarely used.