andrew@alice.att.com (Andrew Hume) (03/17/91)
A comment from a recent message in the seemingly endless chatter about find traversing sym links observed that symbolic (and hard) links have warts but what was the alternative? Before describing an answer, I wish to make clear the distinction between file systems and file servers. A file server (or more precisely, a file service) presents files (including directories, devices etc) with a particular set of properties. Some of these might be an absolute, fixed namespace, the presence of symbolic and/or hard links and so on. A file system is something an application program sees, or rather, what the file system related system calls (open, read, write etc) act on. It used to be that both of these were the same. With the advent of NFS-style file servers, the file system is an amalgam of file servers, some local and some remote, with the namespaces of teh file servers attached at various points in the aplication's namespace. With things like the auto-mounter, the relation between the application's namespace and the various file servers is no longer staticly defined. The Plan 9 file server, or more exactly, the protocol for communicating with file servers, does not support any kind of link. The Plan 9 operating system, however, supports arbitrary mounting of processes and file servers's filesystems at arbitrary places in the namespace. This can be used to accomplish (but probably not all) of the things links do. The important things to note are that this is an ephemeral artifice, done for a process group and will not survive the death of teh process group or a reboot, and secondly, it is a per process group thing (all the namespace is) and NOT a system wide thing. Thus, different process groups can use the same file server but see wildly different file systems. andrew hume andrew@research.att.com