> Observation 1: There doesn't seem to be any provision for moving a > directory from one directory into another directory; that is, moving > it to a different directory on the same <type,device> file system. > > Observation 2: There doesn't seem to be any support for hard links.
In http://cm.bell-labs.com/cm/cs/who/dmr/hist.html Ritchie discusses the structure of the "PDP-7 Unix file system" (see the section with that name). One unusual aspect (for the time) was the separation between the i-list array of i-nodes, each representing a file, and directory files that mapped names to i-list indices (i-numbers). A "link" was just an entry in a directory file, mapping a name to an i-node, and there could be many such links to a given i-node, just as in later versions of Unix, although some of the conventions were rather different. Much later, when Berkeley added symbolic links (following Multics), a distinction was drawn between those links, now called "hard links" and "symbolic" ones. That obscured a deeper distinction: the original form either exposes details of a file system implementation or imposes specific requirements on one (depending on your point of view), but the symbolic link does not. I'd argue that for what applications typically do, it's probably an over-specification, and in an environment such as Plan 9 where many different types of resources are represented by file servers, it's a big nuisance for a small benefit. For instance, structures built on-the-fly as views of data would need to record all the new links added. What anyway is the benefit of links? In Unix, directories were made (by a command) by creating a completely empty directory file, then using sys link to add "." and ".." links into that directory in separate, explicit steps. Files were renamed by creating and removing links. This had a certain simplicity and charm, but also implied constraints on file system implementation. Even in Unix, links weren't extensively used for other forms of aliasing. In Plan 9, mkdir is a system call, and "." and ".." aren't explicitly created; and there's a specific way of renaming a file within its directory. It's perhaps a little more abstract, and links aren't needed to express those operations. Later versions of Unix also added mkdir and rename system calls but absolutely typically, retained links; "." and ".." aren't still implemented as links, for which rename implementations give thanks, so why keep hard links? If you really want an operation to move a file or directory from one place in a hierarchy to another, without always having to copy it, it would be better to express that explicitly.
