5 The Filesystem
5.4 F ILE TYPES
Linux defines seven types of files. Even when developers add something new and wonderful to the file tree (such as the process information listed under/proc), it must still be made to look like one of these seven types:
•
Regular files•
Directories•
Character device filesTable 5.2 Standard directories and their contents
Pathname Contents
/bin Commands needed for minimal system operability /boot Kernel and files needed to load the kernel
/dev Device entries for disks, printers, pseudo-terminals, etc.
/etc Critical startup and configuration files /home Home directories for users
/lib Libraries and parts of the C compiler
/media Mount points for filesystems on removable media
/opt Optional application software packages (not yet widely used) /proc Information about all running processes
/root Home directory of the superuser (often just /)
/sbin Commands for booting, repairing, and recovering the system /tmp Temporary files that may disappear between reboots /usr Hierarchy of secondary files and commands
/usr/bin Most commands and executable files /usr/include Header files for compiling C programs
/usr/lib Libraries; also, support files for standard programs /usr/local Local software (software you write or install)
/usr/local/bin Local executables
/usr/local/etc Local system configuration files and commands /usr/local/lib Local support files
/usr/local/sbin Statically linked local system maintenance commands /usr/local/src Source code for /usr/local/*
/usr/man On-line manual pages
/usr/sbin Less essential commands for system administration and repair /usr/share Items that might be common to multiple systems (read-only)
/usr/share/man On-line manual pages
/usr/src Source code for nonlocal software packages (not widely used) /var System-specific data and configuration files
/var/adm Varies: logs, system setup records, strange administrative bits /var/log Various system log files
/var/spool Spooling directories for printers, mail, etc.
/var/tmp More temporary space (preserved between reboots)
The Filesystem
5.4 File types 77
•
Block device files•
Local domain sockets•
Named pipes (FIFOs)•
Symbolic linksYou can determine the type of an existing file with ls -ld. The first character of the ls output encodes the type. The following example demonstrates that /usr/include is a directory:
$ls -ld /usr/include
drwxr-xr-x 27 root root 4096 Jul 15 20:57 /usr/include
ls uses the codes shown in Table 5.3 to represent the various types of files.
As you can see from Table 5.3, rm is the universal tool for deleting files you don’t want anymore. But how would you delete a file named, say, -f? It’s a perfectly legiti-mate filename under most filesystems, but rm -f doesn’t work because the -f is inter-preted as an rmflag. The answer is either to refer to the file by a more complete path-name (such as ./-f) or to use rm’s -- argument to tell it that everything that follows is a filename and not an option (i.e., rm -- -f).
Filenames that contain control characters present a similar problem since reproduc-ing these names from the keyboard can be difficult or impossible. In this situation, you can use shell globbing (pattern matching) to identify the files to delete. When you use pattern matching, it’s a good idea to get in the habit of using the-i option to rm to make rmconfirm the deletion of each file. This feature protects you against deleting any “good” files that your pattern inadvertently matches. For example, to delete a file named foo<Control-D>bar, you could use
$ls
foo?bar foose kde-root
$rm -i foo*
rm: remove `foo\004bar'? y rm: remove `foose'? n
Table 5.3 FIle-type encoding used by ls
File type Symbol Created by Removed by
Regular file - editors, cp, etc. rm
Directory d mkdir rmdir,rm -r
Character device file c mknod rm
Block device file b mknod rm
Local domain socket s socket(2) rm
Named pipe p mknod rm
Symbolic link l ln -s rm
Note that ls shows the control character as a question mark, which can be a bit de-ceptive.6 If you don’t remember that ? is a shell pattern-matching character and try to rm foo?bar, you might potentially remove more than one file (although not in this example). -i is your friend!
To delete the most horribly named files, you may need to resort to rm -i *.
Another option for removing files with squirrely names is to use an alternative inter-face to the filesystem such as emacs’s dired mode or a visual tool such as Nautilus.
Regular files
A regular file is just a bag o’ bytes; Linux imposes no structure on its contents. Text files, data files, executable programs, and shared libraries are all stored as regular files. Both sequential and random access are allowed.
Directories
A directory contains named references to other files. You can create directories with mkdir and delete them with rmdir if they are empty. You can delete nonempty di-rectories with rm -r.
The special entries “.” and “..” refer to the directory itself and to its parent directory;
they may not be removed. Since the root directory has no parent directory, the path
“/..” is equivalent to the path “/.” (and both are equivalent to /).
A file’s name is stored within its parent directory, not with the file itself. In fact, more than one directory (or more than one entry in a single directory) can refer to a file at one time, and the references can have different names. Such an arrangement creates the illusion that a file exists in more than one place at the same time.
These additional references (“links”) are indistinguishable from the original file; as far as Linux is concerned, they are equivalent. Linux maintains a count of the num-ber of links that point to each file and does not release the file’s data blocks until its last link has been deleted. Links cannot cross filesystem boundaries.
References of this sort are usually called “hard links” these days to distinguish them from symbolic links, which are described below. You create hard links with ln and remove them with rm.
It’s easy to remember the syntax of ln if you keep in mind that it mirrors that of cp.
The commandcp oldfile newfilecreates a copy ofoldfilecallednewfile,andln oldfile newfile makes the name newfile an additional reference to oldfile.
It is important to understand that hard links are not a distinct type of file. Instead of defining a separate “thing” called a hard link, the filesystem simply allows more than one directory entry to point to a file. In addition to the file’s contents, the underlying attributes of the file (such as ownerships and permissions) are also shared.
6. ls -b shows the special characters as octal numbers, which can be helpful if you need to identify them specifically. <Control-A> is 1 (\001 in octal), <Control-B> is 2, and so on.
The Filesystem
5.4 File types 79
Character and block device files
See Chapter 28 for more information about devices and drivers.
Device files allow programs to communicate with the system’s hardware and periph-erals. When the kernel is configured, modules that know how to communicate with each of the system’s devices are linked in.7 The module for a particular device, called a device driver, takes care of the messy details of managing the device.
Device drivers present a standard communication interface that looks like a regular file. When the kernel is given a request that refers to a character or block device file, it simply passes the request to the appropriate device driver. It’s important to distin-guish device files from device drivers, however. The files are just rendezvous points that are used to communicate with the drivers. They are not the drivers themselves.
Character device files allow their associated drivers to do their own input and out-put buffering. Block device files are used by drivers that handle I/O in large chunks and want the kernel to perform buffering for them. In the past, a few types of hard-ware were represented by both block and character device files, but that configura-tion is rare today.
Device files are characterized by two numbers, called the major and minor device numbers. The major device number tells the kernel which driver the file refers to, and the minor device number typically tells the driver which physical unit to address.
For example, major device number 6 on a Linux system indicates the parallel port driver. The first parallel port (/dev/lp0)would have major device number 6 and minor device number 0.
Drivers can interpret the minor device numbers that are passed to them in whatever way they please. For example, tape drivers use the minor device number to deter-mine whether the tape should be rewound when the device file is closed.
You can create device files withmknodand remove them withrm. However, it’s rarely necessary to create device files by hand. Most distributions use udev to auto-matically create and remove device files as hardware is detected by the kernel. udev keeps /dev tidy by limiting the number of spurious device files and by ensuring that the device numbers assigned to files are consistent with those expected by the kernel.
See Chapter 28, Drivers and the Kernel, for more information.
An older script called MAKEDEV makes a good backup for udev in case you ever do need to create device files by hand. The script encodes the conventional names and device numbers for various classes of device so that you need not look up these values yourself. For example, MAKEDEV pty creates the device files for pseudo-terminals.
If you ever need to determine what major and minor device numbers are used by a driver, you can find this information in the driver’s man page in section 4 of the manuals (e.g, man 4 tty).
7. These modules can also be loaded dynamically by the kernel.
Local domain sockets
Sockets are connections between processes that allow them to communicate hygieni-cally. Linux provides several different kinds of sockets, most of which involve the use of a network. Local domain sockets are accessible only from the local host and are referred to through a filesystem object rather than a network port. They are some-times known as “UNIX domain sockets.”
See Chapter 10 for more information about syslog.
Although socket files are visible to other processes as directory entries, they cannot be read from or written to by processes not involved in the connection. Some stan-dard facilities that use local domain sockets are the printing system, the X Window System, and syslog.
Local domain sockets are created with the socket system call and can be removed with thermcommand or theunlinksystem call once they have no more users.
Named pipes
Like local domain sockets, named pipes allow communication between two pro-cesses running on the same host. They’re also known as “FIFO files” (FIFO is short for the phrase “first in, first out”). You can create named pipes with mknod and remove them with rm.
Symbolic links
A symbolic or “soft” link points to a file by name. When the kernel comes upon a symbolic link in the course of looking up a pathname, it redirects its attention to the pathname stored as the contents of the link. The difference between hard links and symbolic links is that a hard link is a direct reference, whereas a symbolic link is a reference by name; symbolic links are distinct from the files they point to.
You create symbolic links with ln -s and remove them with rm. Since they can con-tain arbitrary paths, they can refer to files on other filesystems or to nonexistent files.
Multiple symbolic links can also form a loop.
A symbolic link can contain either an absolute or a relative path. For example,
#ln -s archived/secure /var/log/secure
links /var/log/secure to /var/log/archived/securewith a relative path. It creates the symbolic link/var/log/securewith a target of “archived/secure”, as demonstrated by this output from ls:
$ls -l /var/log/secure
lrwxrwxrwx 1 root root 18 2005-07-05 12:54 /var/log/secure -> archived/secure8
Theentire /var/log directory could be moved somewhere else without causing the symbolic link to stop working (not that moving this directory is advisable).
8. The file permissions that ls shows for a symbolic link, lrwxrwxrwx, are dummy values. Permission to create, remove, or follow the link is controlled by the containing directory, whereas read, write, and execute permission on the link target are granted by the target’s own permissions. Therefore, symbolic links do not need (and do not have) any permission information of their own.
The Filesystem