An alternative to links?

[Andrew Hume]

	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 at research.att.com