PFS is organized to support multiple views of many file systems. Currently there are two views supported, each looking at the Unix file system on the machine hosting PCedar.

The first view is called "-ux" (pronounced "ucks") and provides a fairly vanilla unix-like picture of the file system. That is, file names are treated case-sensitively and there are no versions. (But note that opening a file requesting it be created will rename any existing file and create a new file.) In the -ux view directory boundaries are quite significant and no automatic directory creation is provided.

[Wart: there is no way to create a directory.]

The second view is called "-vux" (pronounced "vucks") and provides case-insensitive file names and versions. The -vux view is compatible with the -NFS remote file view in the Cedar7.0 RemoteFile system. The -vux view automatically creates directories as needed when creating or storing files.

All the PFS procedures that operate on named files (as opposed to open files) take the names in the form of a PFSNames.PATH. PATHs are immutable objects that can easily be manipulated with procedures from PFSNames produce new PATHs. A PATH is, conceptually, a sequence of Components. Each Component is, conceptually, a ROPE and a Version. A Version is either a numeric version or a version variable, or none. As of now, all the PATHs we're using have no versions except in the last component. The idea of using PATHs is to make it easy to pull names apart and put them together on a directory by directory basis.

The PFS interface provides procedures PathFromRope and RopeFromPath for going back and forth to conventional Cedar and Unix file names such as "[PCedar2.0]<Top>PFS-Suite.df" and "/pcedar2.0/top/pfs-suite.df". In fact, the syntax of Unix-style names has been extended to allow a view-name followed by a colon to precede the initial /. So "-vux:/pseudo/pcedar2.0" can also be translated to a PATH.

PFSNames has facilities for programs to construct PATHs from components. These would be used, for example, by a program that converted to some other file name syntax.

Every Cedar process has a WorkingDirectory. Relative PATHs passed to PFS procedures (except PFS.RopeFromPath) are interpreted relative to the process's working directory. The working directory is not used in interpreting absolute file names passed to PFS.

[Wart: The WorkingDirectory process property is currently stored as a ROPE and has to be converted to a PATH each time it is used. This is so that PFS and the other xFS's currently used in PCedar all agree on the working directory. This is only a performance consideration but it needs fixing.]

The prefix map is a list of PATH pairs. The second element of each pair must be an absolute path including a valid view name. Following completion of the working directory processing mentioned above, every PATH is translated according to the current prefix map as follows: find the longest first element in the map matching the presented name and replace the matching subname by the second element. The matching is caseless and no patterns are allowed in the prefix map.

PFS creates an initial prefix map with the pair ["/", "-ux:/"] giving unix-style access to the Unix system's root directory. Notice that this matches any name presented to PFS, so all names can be successfully translated by this prefix map.

One can create one's own prefix map and have PFS use it instead of the default map. Whenever PFSPrefixMap wants the default prefix map, it first looks for a process property, keyed by $PrefixTableList.

The PFS interface uses a RECORD type called UniqueID in places where FS used BasicTime.GMT's. This gives us the possibility of more resolution in times and also the opportunity to avoid conflicts between creating machines in choosing UniqueIDs. However, we don't have any servers that can store complete UniqueIDs so only the GMT field is significant, as of now.