October 17, 2001, 2:28 PM — Despite all of the work that has been done with
object-oriented systems and user interfaces, the Unix filesystem is
the primary mechanism we use to locate and interact with our data. The
hierarchical namespace is simple and relatively easy to use -- until
you begin adding symbolic links, NFS mounts, removable media, and
other wormholes that take you from one disk to another with little
warning. Large Unix environments stress the filesystem in new and
creative ways: Processes can go file-crazy and run into system-resource
limitations. Users who have yet to discover the wonder of directories
complain of terrible system performance, or just when you think your list
of headaches is complete, you try to unmount a CD-ROM but continually
get "filesystem busy" error messages, or you promise to remove the
mailbox of a user who is hanging you up -- as soon as you determine
his or her identity.
This month, we'll sort through some filesystem navigation issues.
We'll look at open() to see how processes find files, and
examine some performance issues. From there, it's off to the links --
hard and symbolic -- to see how they alter paths through the
filesystem. Finally, we'll look at the tools available to find the
user associated with an open file or directory. While we may not offer
any solutions to the deep-versus-wide directory layout argument, we'll
try to make sure that no matter what you call your files, you'll get the
right bits.
Open duplicity
We see the filesystem as a tree of directories and filenames. These
physical names aren't used inside of a process. Logical
names known as file descriptors, or file handles, are used to
identify a file for reading or writing. Unix file descriptors are
integers returned by the open() or dup()
system calls. Pass a filesystem pathname to open() along
with the read or write permissions you want, and open()
returns a file descriptor or an error:
int fd;
fd = open("/home/stern/cols/sep95.doc", O_RDONLY);
if (fd < 0) {
fprintf(stderr, "cannot open file\n");
exit(1);
}
You can open special (raw) devices or special files like Unix domain
sockets using a similar code fragment. File descriptors are maintained
on a per-process basis, in the same kernel data structures that keep
track of the stack, address space, and signal handlers. Every process
starts out with file descriptors 0, 1, and 2 assigned to the standard
input, output, and error streams, respectively. Each subsequent call
to open() returns the next available file handle. When
you call close() on a file descriptor, that handle is the
next one used by open(). The integer is really just an
index into a table of per-process file descriptors that point to the
system open file table. The system file table points to other
file-specific information like inodes, NFS server addresses, or
protocol-control blocks for file descriptors associated with sockets.
What's the point of dup() if open() is the
primary mechanism for converting pathnames to file handles? When you
want to use the same file for two output streams, such as
stdout and stderr, use dup() to
copy one descriptor into another. The following code segment closes
the default stdout and stderr streams and pumps both into a new file:
int fd;
close(1);
close(2);
fd = open("/home/stern/log/errors", O_WRONLY|O_CREATE);
dup(fd);
Because the file descriptors for stdout and stderr were closed before
the calls to open() and dup(), these handles
are re-used.
Open file descriptors are preserved when new processes are created
with fork() and vfork(), so any process that
gets started via exec() inherits the open file
descriptors left by the calling process. Here's a simple example of
using dup() and fork() to set up a pipe
between two processes:
