Pathname lookup using dir_stacks

Implemented in: src/resolve-filename.h, src/resolve-filename.c

Plash's FsObj interface for accessing file and directory objects does not provide a way to find an object's parent directory. However, Plash still needs to implement the ".." pathname element in Unix pathnames. This is implemented by the filename resolver in a layer above FsObj.

The filename resolver takes the parent of an object X to be the directory that X was reached through (after symlink expansion).

The filename resolver maintains a stack of directory object references, called a dir_stack.

FsOp represents the current working directory as a dir_stack.

A dir_stack includes the leafnames of the directories. getcwd() is implemented by concatenating these leafnames. (Note that most of the time storing the leafnames is not necessary. Most dir_stack objects are short-lived and only created for resolving a pathname, and will not be kept as a current working directory.)

dir_stacks are implemented as immutable objects.

Under Plash, DirectoryFDs refer to dir_stacks.

Consequences

Since getcwd() only returns the pathname stored in the dir_stack, the pathname it returns will not change when the current working directory is renamed, moved or deleted.

The following sequence of calls:

chdir("leafname");
chdir("..");

has no effect, provided the first call is successful. This contrasts with the usual Unix semantics, in which the "leafname" directory could have been moved between the two chdir() calls. Tools such as "rm" which recursively traverse directory structures use fchdir() to avoid this race condition. This race condition does not exist for programs running under Plash.