Last month, I wrote about Linux’s file access API.
For this month’s column, I’m gong to talk about some of the other
important file-related system calls, and touch on how the kernel file
implementation affects the system call
interface.
Last month, I wrote about Linux’s file access API. For this month’s column, I’m gong to talk about some of the other important file-related system calls, and touch on how the kernel file implementation affects the system call interface.
In the POSIX world, it’s important to remember that a single file can have more than one name (that is, if it even has a name), and can also have symbolic links pointing to it. This means that a file does not necessarily have to have a name, and even if it does, it does not have to be a unique name. Files exist separately from their names as far as the filesystem is concerned.
Figure 1: A file that is opened by two different processes will still have a single in-core inode, although the processes each have different file descriptors and file structures.
The most obvious examples of this are symbolic links, also called symlinks or soft links. Symlinks are special files that specify another filename. Most system calls (including open() “follow the symlink” if they are told to access the symbolic link. They are then referred to a file by the symlink (if you’re familiar with HTTP, think of these as a bit like a server redirect). For example, the file /etc/localtime is normally a symbolic link to the file…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
