This lesson makes a small digression into areas that some readers will know about and some won't. Before learning any more about filesystems, it is important to know about some basic concepts. About half the lesson will be devoted to these ("Background information"). After that, we can start getting some practical work done, and learn how to mount and unmount sections of the filesystem. This will come in lesson 3.
I'll be assuming you're familiar with relative paths. Very briefly:
Every process has a working directory. This is the directory the
process is running "inside". To see the current working directory of your shell,
pwd, which stands for Print Working
Directory. Here's what happens when I use it:
What is a shell? A shell is a program just like any other - there is
nothing particularly mystical about it. You can interact with a shell by
typing a command into it. It will run this command, and, when it is finished,
present the prompt (in my case,
Which shell is started when you log in is determined by your user's entry
If you want to try out a different shell to the one you're using, you can
start it just like any other program. For example, to try out the C shell,
The shell prompt is very configurable. You'll probably notice that my use
The important thing here is the third line. I change directory into
/usr/, and then into
bin/. The net effect is
therefore to put me in
/usr/bin. This is called a relative
path - it depends on the current working directory. If I had executed
cd bin/ when my working directory was
/, I would
end up in
Another thing I demonstrate is the
../ directory. In any
../ refers to the directory above it (
an exception - its
../ directory refers to itself).
./ refers to the current directory. Why is this
useful? Well, it's not that frequently used. The main application is forcing a
shell to run something in the local directory. For example, if I just typed
somecommand into my shell, the shell would search all the
directories in the
PATH environment variable for an executable file
somecommand. If you type
shell sees that it's a relative path, and doesn't search for the program.
Instead, it just runs it from
./ - the current working directory.
Each process has an identity attached to it. For each process, the operating
system kernel stores a UID - User ID. When you log in, the
UID of your shell (and, therefore, all its child processes such as text editors,
web browsers, and so on) is the number given to your username in the file
/etc/passwd. The process also carries one or more GIDs -
Group IDs. When you log in, your shell (and all its descendants)
acquire the GIDs of all the groups of which
/etc/group lists you as
Each file or directory also has a UID, and one GID. It also has three sorts of permission - read, write, and execute. There are three versions of these permissions - one each for "user", "group", and "other".
Let's see what that looks like:
meredydd@rhodium:~$ ls -l snapshot.tgz -rw-r--r-- 1 meredydd users 10007 Jun 20 00:08 snapshot.tgz meredydd@rhodium:~$
If we look at the output of ls -l, we see that the file
snapshot.tgz is owned by the UID which corresponds to the user
/etc/passwd, and the GID which corresponse to "users"
What's more, it has a permission set of
rw-r--r-- (ignore the
first dash - that's a '
d' if you're looking at a
directory). This means that the owner (me) has read and write access (but not
execute), the group ("users") has read access but not write or execute, and the
same goes for everyone else.
OK, that's a whistle-stop tour of file permissions. The one remaining topic is how this applies to directories. With directories, one needs execute permission to access anything in that directory, read permission to list the files in the directory, and write permission to create files there.
Symbolic links, sometimes called "soft links", are another topic which tends to confuse migrating users from other operating systems. The concept is somewhat akin to a shortcut - a symbolic link acts just like its target.
The easiest way to demonstrate symbolic links is to make one and look at how
they behave. You can make one with the
ln command, passing it the
You can follow through this example yourself - all you need is a directory
web/, and a directory called
backups, and to
change every reference to
/home/meredydd to your own home
Let's walk through that, shall we?
backups/folder has nothing in it.
|Make a link||Make it symbolic||Target path||Where to put the link|
backups/folder, to show that it does indeed contain a link to
/home/meredydd/web/, called "
backups/web/acts just like
web/. It's not a copy - if you change something in one, it will be reflected in the other. This is a very useful - the example here is one I use myself. I have a
backups/folder. In it, I place symbolic links to everything I want backed up on a regular basis. That way, I can just run a script which copies everything in that directory to my backup server - it will follow the links, and back up all my work.
Symlinks are not quite perfect. Remember the
If you look at the directory
If you think about it, it does make sense - a directory's
It's not only directories which can have symbolic links made to them.
Ordinary files, and even special files like devices (again, we'll come to this
in a few lessons' time), can be linked to just like anything else. It's also
worth noting that because of the unified filesystem I talked about in lesson 1,
symbolic links don't care about where the files they're linking to are stored.
You can create a symlink on your hard drive to a file on your floppy drive, and
the system won't even blink.
One more important point, and one you should never forget: Symbolic links are relative!. I can't tell
you how many times this one has caught me out. The path you give as a target to
ln command will be relative to the directory in which the link
So, for example, if I had executed the command:
ln -s web/ backups/
...it would have created the link, but then failed horribly (with a "file not
found" error) when I tried to follow it. The reason? The path
web/" would have been evaluated relative to the directory where
the link is (
/home/meredydd/backups/), not the directory we
were in when we created the link (
A guaranteed safe method of avoiding this is to use absolute paths -
paths beginning with a
/, which are the same wherever they are
evaluated from. For example,
/usr/bin/ is an absolute path, and
bin/ is a relative path which only refers to the same directory if
it's evaluated in
A good (if somewhat technical) explanation of links is available on the Linux
man page for the
ln command. "
man ln" should do it.
Follow through the example here. Try it again, with different directories. Play around. See what happens when you create circular links (links which point to their own parent directory, or even to themselves). As always, tell me how you get on, and ask me if you have any questions at all.
Next lesson will introduce us to some of the details of mounting and unmounting sections of the filesystem, including devices, filesystem drivers, and some actual concrete exercises for once.