A program does not always have to specify files by fully qualified pathnames. At any time, each process has an associated directory, called the current working directory, that it uses for pathname resolution. If a pathname does not start with /, the program prepends the fully qualified path of the current working directory. Hence, pathnames that do not begin with / are sometimes called relative pathnames because they are specified relative to the fully qualified pathname of the current directory. A dot (.) specifies the current directory, and a dot-dot (..) specifies the directory above the current directory. The root directory has both dot and dot-dot pointing to itself.

cd /dirA/dirB

The PWD environment variable specifies the current working directory of a process. Do not directly change this variable, but rather use the getcwd function to retrieve the current working directory and use the chdir function to change the current working directory within a process.

The chdir function causes the directory specified by path to become the current working directory for the calling process.

SYNOPSIS

   #include <unistd.h>

   int chdir(const char *path);
                                           POSIX

If successful, chdir returns 0. If unsuccessful, chdir returns –1 and sets errno. The following table lists the mandatory errors for chdir.

char *directory = " /tmp";

if (chdir(directory) == -1)
   perror("Failed to change current working directory to /tmp");

The getcwd function returns the pathname of the current working directory. The buf parameter of getcwd represents a user-supplied buffer for holding the pathname of the current working directory. The size parameter specifies the maximum length pathname that buf can accommodate, including the trailing string terminator.

SYNOPSIS

   #include <unistd.h>

   char *getcwd(char *buf, size_t size);
                                                    POSIX

If successful, getcwd returns a pointer to buf. If unsuccessful, getcwd returns NULL and sets errno. The following table lists the mandatory errors for getcwd.

If buf is not NULL, getcwd copies the name into buf. If buf is NULL, POSIX states that the behavior of getcwd is undefined. In some implementations, getcwd uses malloc to create a buffer to hold the pathname. Do not rely on this behavior.

You should always supply getcwd with a buffer large enough to fit a string containing the pathname. Program 5.1 shows a program that uses PATH_MAX as the buffer size. PATH_MAX is an optional POSIX constant specifying the maximum length of a pathname (including the terminating null byte) for the implementation. The PATH_MAX constant may or may not be defined in limits.h. The optional POSIX constants can be omitted from limits.h if their values are indeterminate but larger than the required POSIX minimum. For PATH_MAX, the _POSIX_PATH_MAX constant specifies that an implementation must accommodate pathname lengths of at least 255. A vendor might allow PATH_MAX to depend on the amount of available memory space on a specific instance of a specific implementation.

#include <limits.h>
#include <stdio.h>
#include <unistd.h>
#ifndef PATH_MAX
#define PATH_MAX 255
#endif

int main(void) {
    char mycwd[PATH_MAX];

    if (getcwd(mycwd, PATH_MAX) == NULL) {
        perror("Failed to get current working directory");
        return 1;
    }
    printf("Current working directory: %s
", mycwd);
    return 0;
}

A more flexible approach uses the pathconf function to determine the real value for the maximum path length at run time. The pathconf function is one of a family of functions that allows a program to determine system and runtime limits in a platform-independent way. For example, Program 2.10 uses the sysconf member of this family to calculate the number of seconds that a program runs. The sysconf function takes a single argument, which is the name of a configurable systemwide limit such as the number of clock ticks per second (_SC_CLK_TCK) or the maximum number of processes allowed per user (_SC_CHILD_MAX).

The pathconf and fpathconf functions report limits associated with a particular file or directory. The fpathconf takes a file descriptor and the limit designator as parameters, so the file must be opened before a call to fpathconf. The pathconf function takes a pathname and a limit designator as parameters, so it can be called without the program actually opening the file. The sysconf function returns the current value of a configurable system limit that is not associated with files. Its name parameter designates the limit.

SYNOPSIS

   #include <unistd.h>

   long fpathconf(int fildes, int name);
   long pathconf(const char *path, int name);
   long sysconf(int name);
                                                      POSIX

If successful, these functions return the value of the limit. If unsuccessful, these functions return –1 and set errno. The following table lists the mandatory errors.

Program 5.2 shows a program that avoids the PATH_MAX problem by first calling pathconf to find the maximum pathname length. Since the program does not know the length of the path until run time, it allocates the buffer for the path dynamically.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void) {
   long maxpath;
   char *mycwdp;

   if ((maxpath = pathconf(".", _PC_PATH_MAX)) == -1) {
      perror("Failed to determine the pathname length");
      return 1;
   }
   if ((mycwdp = (char *) malloc(maxpath)) == NULL) {
      perror("Failed to allocate space for pathname");
      return 1;
   }
   if (getcwd(mycwdp, maxpath) == NULL) {
      perror("Failed to get current working directory");
      return 1;
   }
   printf("Current working directory: %s
", mycwdp);
   return 0;
}

A user executes a program in a UNIX shell by typing the pathname of the file containing the executable. Most commonly used programs and utilities are not in the user’s current working directory (e.g., vi, cc). Imagine how inconvenient it would be if you actually had to know the locations of all system executables to execute them. Fortunately, UNIX has a method of looking for executables in a systematic way. If only a name is given for an executable, the shell searches for the executable in all possible directories listed by the PATH environment variable. PATH contains the fully qualified pathnames of important directories separated by colons.

/usr/bin:/etc:/usr/local/bin:/usr/ccs/bin:/home/robbins/bin:.

Remember that the shell does not search subdirectories of directories in the PATH unless they are also explicitly specified in the PATH. If in doubt about which version of a particular program you are actually executing, use which to get the fully qualified pathname of the executable. The which command is not part of POSIX, but it is available on most systems. Section 5.5 describes how you can write your own version of which.

It is common for programmers to create a bin directory for executables, making bin a subdirectory of their home directories. The PATH of Example 5.5 contains the /home/robbins/bin directory. The bin directory appears before dot (.), the current directory, in the search path leading to the problem discussed in the next exercise.

Resist the temptation to put the dot (.) at the beginning of the PATH in spite of the problem mentioned in Exercise 5.6. Such a PATH specification is regarded as a security risk and may lead to strange results when your shell executes local programs instead of the standard system programs of the same name.

This section describes three functions for retrieving file status information. The fstat function accesses a file with an open file descriptor. The stat and lstat functions access a file by name.

The lstat and stat functions each take two parameters. The path parameter specifies the name of a file or symbolic link whose status is to be returned. If path does not correspond to a symbolic link, both functions return the same results. When path is a symbolic link, the lstat function returns information about the link whereas the stat function returns information about the file referred to by the link. Section 5.4 explains symbolic links. The buf parameter points to a user-supplied buffer into which these functions store the information.

SYNOPSIS

  #include <sys/stat.h>

  int lstat(const char *restrict path, struct stat *restrict buf);
  int stat(const char *restrict path, struct stat *restrict buf);
                                                                           POSIX

If successful, these functions return 0. If unsuccessful, they return –1 and set errno. The restrict modifier on the arguments specifies that path and buf are not allowed to overlap. The following table lists the mandatory errors for these functions.

The struct stat structure, which is defined in sys/stat.h, contains at least the following members.

dev_t     st_dev;       /* device ID of device containing file */
ino_t     st_ino;       /* file serial number */
mode_t    st_mode;      /* file mode */
nlink_t   st_nlink;     /* number of hard links */
uid_t     st_uid;       /* user ID of file */
gid_t     st_gid;       /* group ID of file */
off_t     st_size;      /* file size in bytes (regular files) */
                        /* path size (symbolic links) */
time_t    st_atime;     /* time of last access */
time_t    st_mtime;     /* time of last data modification */
time_t    st_ctime;     /* time of last file status change */

#include <stdio.h>
#include <time.h>
#include <sys/stat.h>

void printaccess(char *path) {
   struct stat statbuf;

   if (stat(path, &statbuf) == -1)
      perror("Failed to get file status");
   else
      printf("%s last accessed at %s", path, ctime(&statbuf.st_atime));
}

#include <stdio.h>
#include <time.h>
#include <sys/stat.h>

void printaccessmodbad(char *path) {
   struct stat statbuf;

   if (stat(path, &statbuf) == -1)
      perror("Failed to get file status");
   else
     printf("%s accessed: %s modified: %s", path,
            ctime(&statbuf.st_atime), ctime(&statbuf.st_mtime));
}

#include <stdio.h>
#include <string.h>
#include <time.h>
#include <sys/stat.h>
#define CTIME_SIZE 26

void printaccessmod(char *path) {
   char atime[CTIME_SIZE];   /* 26 is the size of the ctime string */
   struct stat statbuf;

   if (stat(path, &statbuf) == -1)
      perror("Failed to get file status");
   else {
      strncpy(atime, ctime(&statbuf.st_atime), CTIME_SIZE - 1);
      atime[CTIME_SIZE - 2] = 0;
      printf("%s accessed: %s modified: %s", path, atime,
               ctime(&statbuf.st_mtime));
   }
}

The fstat function reports status information of a file associated with the open file descriptor fildes. The buf parameter points to a user-supplied buffer into which fstat writes the information.

SYNOPSIS

  #include <sys/stat.h>

  int fstat(int fildes, struct stat *buf);
                                                   POSIX

If successful, fstat returns 0. If unsuccessful, fstat returns –1 and sets errno. The following table lists the mandatory errors for fstat.

The file mode member st_mode specifies the access permissions of the file and the type of file. Table 4.1 on page 105 lists the POSIX symbolic names for the access permission bits. POSIX specifies the macros of Table 5.1 for testing the st_mode member for the type of file. A regular file is a randomly accessible sequence of bytes with no further structure imposed by the system. UNIX stores data and programs as regular files. Directories are files that associate filenames with locations, and special files specify devices. Character special files represent devices such as terminals; block special files represent disk devices. The ISFIFO tests for pipes and FIFOs that are used for interprocess communication.Chapter 6 discusses special files, and Chapter 14 discusses interprocess communication based on message queues, semaphores and shared memory.

#include <stdio.h>
#include <time.h>
#include <sys/stat.h>

int isdirectory(char *path) {
   struct stat statbuf;

   if (stat(path, &statbuf) == -1)
      return 0;
   else
      return S_ISDIR(statbuf.st_mode);
}

POSIX does not mandate any particular representation of files on disk, but traditionally UNIX files have been implemented with a modified tree structure, as described in this section. Directory entries contain a filename and a reference to a fixed-length structure called an inode. The inode contains information about the file size, the file location, the owner of the file, the time of creation, time of last access, time of last modification, permissions and soon.

Figure 5.3 shows the inode structure for a typical file. In addition to descriptive information about the file, the inode contains pointers to the first few data blocks of the file. If the file is large, the indirect pointer is a pointer to a block of pointers that point to additional data blocks. If the file is still larger, the double indirect pointer is a pointer to a block of indirect pointers. If the file is really huge, the triple indirect pointer contains a pointer to a block of double indirect pointers. The word block can mean different things (even within UNIX). In this context a block is typically 8K bytes. The number of bytes in a block is always a power of 2.

Figure 5.3. Schematic structure of a traditional UNIX file.

The tree-structured representation of files is fairly efficient for small files and is also flexible if the size of the file changes. When a file is created, the operating system finds free blocks on the disk in which to place the data. Performance considerations dictate that blocks of the same file should be located close to one another on the disk to reduce the seek time. It takes about twenty times as long to read a 16-megabyte file in which the data blocks are randomly placed than one in which the data blocks are contiguous.

When a system administrator creates a file system on a physical disk partition, the raw bytes are organized into data blocks and inodes. Each physical disk partition has its own pool of inodes that are uniquely numbered. Files created on that partition use inodes from that partition’s pool. The relative layout of the disk blocks and inodes has been optimized for performance.

POSIX does not require that a system actually represent its files by using inodes. The ino_t st_ino member of the struct stat is now called a file serial number rather than an inode number. POSIX-compliant systems must provide the information corresponding to the mandatory members of the struct stat specified on page 155, but POSIX leaves the actual implementation unspecified. In this way, the POSIX standard tries to separate implementation from the interface.

A directory is a file containing a correspondence between filenames and file locations. UNIX has traditionally implemented the location specification as an inode number, but as noted above, POSIX does not require this. The inode itself does not contain the filename. When a program references a file by pathname, the operating system traverses the file system tree to find the filename and inode number in the appropriate directory. Once it has the inode number, the operating system can determine other information about the file by accessing the inode. (For performance reasons, this is not as simple as it seems, because the operating system caches both directory entries and inode entries in main memory.)

A directory implementation that contains only names and inode numbers has the following advantages.

You can create additional links to a file with the ln shell commandor the link function. The creation of the new link allocates a new directory entry and increments the link count of the corresponding inode. The link uses no other additional disk space.

When you delete a file by executing the rm shell command or by calling the unlink function from a program, the operating system deletes the corresponding directory entry and decrements the link count in the inode. It does not free the inode and the corresponding data blocks unless the operation causes the link count to be decremented to 0.

The link function creates a new directory entry for the existing file specified by path1 in the directory specified by path2.

SYNOPSIS

   #include <unistd.h>

   int link(const char *path1, const char *path2);
                                                           POSIX

If successful, the link function returns 0. If unsuccessful, link returns –1 and sets errno. The following table lists the mandatory errors for link.

ln /dirA/name1 /dirB/name2

#include <stdio.h>
#include <unistd.h>

if (link("/dirA/name1", "/dirB/name2") == -1)
   perror("Failed to make a new link in /dirB");

Figure 5.4 shows a schematic of /dirA/name1 before the ln command of Example 5.15 or the link function of Example 5.16 executes. Figure 5.5 shows the result of linking.

Figure 5.5. Two hard links to the same file shown in Figure 5.4.

The ln command (or link function) creates a link (directory entry) that refers to the same inode as dirA/name1. No additional disk space is required, except possibly if the new directory entry increases the number of data blocks needed to hold the directory information. The inode now has two links.

The unlink function removes the directory entry specified by path. If the file’s link count is 0 and no process has the file open, the unlink frees the space occupied by the file.

SYNOPSIS

   #include <unistd.h>

   int unlink(const char *path);
                                           POSIX

If successful, the unlink function returns 0. If unsuccessful, unlink returns –1 and sets errno. The following table lists the mandatory errors for unlink.

Figure 5.6. Situation after a text editor changes a file. The original file had inode 12345 and two hard links before editing (i.e., the configuration of Figure 5.5).

Figure 5.7. Situation after one file is changed with an editor that makes a backup copy.

The behavior illustrated in Exercises 5.17 and 5.18 may be undesirable. An alternative approach would be to have both /dirA/name1 and /dirB/name2 reference the new file. In Exercise 5.22 we explore an alternative sequence of operations that an editor can use.

A symbolic link is a file containing the name of another file or directory. A reference to the name of a symbolic link causes the operating system to locate the inode corresponding to that link. The operating system assumes that the data blocks of the corresponding inode contain another pathname. The operating system then locates the directory entry for that pathname and continues to follow the chain until it finally encounters a hard link and a real file. The system gives up after a while if it doesn’t find a real file, returning the ELOOP error.

Create a symbolic link by using the ln command with the -s option or by invoking the symlink function. The path1 parameter of symlink contains the string that will be the contents of the link, and path2 gives the pathname of the link. That is, path2 is the newly created link and path1 is what the new link points to.

SYNOPSIS

   #include <unistd.h>

   int symlink(const char *path1, const char *path2);
                                                                 POSIX

If successful, symlink returns 0. If unsuccessful, symlink returns –1 and sets errno. The following table lists the mandatory errors for symlink.

ln -s /dirA/name1 /dirB/name2

Figure 5.8. Ordinary file with a symbolic link to it.

if (symlink("/dirA/name1", "/dirB/name2") == -1)
   perror("Failed to create symbolic link in /dirB");

Unlike Exercise 5.17, the ln command of Example 5.19 and the symlink function of Example 5.20 use a new inode, in this case 13579, for the symbolic link. Inodes contain information about the type of file they represent (i.e., ordinary, directory, special, or symbolic link), so inode 13579 contains information indicating that it is a symbolic link. The symbolic link requires at least one data block. In this case, block 15213 is used. The data block contains the name of the file that /dirB/name2 is linked to, in this case, /dirA/name1. The name may be fully qualified as in this example, or it may be relative to its own directory.

Figure 5.9. Situation after editing a file that has a symbolic link.

All the alternatives except the last have serious drawbacks. If the header files are copied to the directory /usr/include/X11, then two copies of these files exist. Aside from the additional disk space required, an update might cause these files to be inconsistent. Moving the files (copying them to the directory /usr/include/X11 and then deleting them from /usr/openwin/share/include/X11) may interfere with operating system upgrades. Having users modify all their programs or makefiles is unreasonable. Another alternative not mentioned above is to use an environment variable to modify the search path for header files.