Linux Kernel Architecture

Chapter 8: The Virtual Filesystem

Inode Data area

data

usr 2

bin 3

share 4

var 10

bin 11

opt 12

X 117

vi 118

emacs 119

data

12

data

10

Figure 8-2: Lookup operation for/usr/bin/emacs.

Symbolic links can be regarded as ‘‘direction pointers‘‘ (at least by user programs) to indicate

the presence of a file at a particular location, although — as we all know — the actual file resides

somewhere else.

Sometimes the namesoft linkis used for links of this kind. This is because the link and link target are not

tightly coupled with each other. A link can be imagined as a directory entry that does not contain any

data but just a pointer to a filename. The link is retained when the target file is deleted. A separate inode

is used for each symbolic link. The data segment of the inode contains a character string that gives the

name of the link target.

With symbolic links, it is possible to distinguish between the original file and the link. This is not the case

with hard links. Once a hard link has been created, it is no longer possible to establish which filename is

the original and which is the hard link. When a hard link is created, a directory entry is generated whose

associated inode uses an existing inode number.

Deleting a symbolic link is not difficult, but the situation with hard links is a little trickier.

Let us assume that a hard link (B) shares the same inode with the original file (A). A user now

wants to deleteA; this normally destroys the associated inode together with its data segment

so that it can be released and subsequently overwritten. Access toBis then no longer possible

because the associated inode and file information no longer exists. Of course, this is not desirable

behavior.

It can be prevented by a counter incorporated in the inode. The counter is incremented each time a hard

link to the file is created. If one of the hard links or, indeed, the original file (because it is impossible

to differentiate between the two) is deleted, the counter is decremented by 1. Only when the counter

has reverted to 0 is it certain that the inode is no longer in use and can therefore be removed from

the system.

8.2.3 Programming Interface

The interface between user processes and the kernel implementation of the VFS is formed, as usual, by

system calls, most of which involve the manipulation of files, directories, and filesystems in general. At

this point, we will not concern ourselves with the specific details of system programming as these are the

subject of many other publications such as [SR05] and [Her03].