Re: [TUHS] moving directories in svr2

[Bakul Shah <bakul@iitbombay.org>]

> On Dec 29, 2021, at 12:42 PM, Richard Salz <rich.salz@gmail.com> wrote:
> 
> https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with:
> 
> Each directory always has at least two entries. The
> name "." in each directory refers to the directory itself. Thus a
> program may read the current directory under the name “.”
> without knowing its complete path name. The name “..” by
> convention refers to the parent of the directory in which it
> appears, that is, to the directory in which it was created.
> The directory structure is constrained to have the form
> of a rooted tree. Except for the special entries “.” and “..”,

Note that "." or ".." entries are not needed if you store the
entire path of the current working dir. in a process'es kernel
state. My guess is *not* storing a path instead of a ptr to
the inode was done to save on memory.

> each directory must appear as an entry in exactly one other,
> which is its parent. The reason for this is to simplify the
> writing of programs which visit subtrees of the directory
> structure, and more important, to avoid the separation of
> portions of the hierarchy. If arbitrary links to directories
> were permitted, it would be quite difficult to detect when
> the last connection from the root to a directory was severed


Every inode has a linkcount so detecting when the last conn.
is severed not a problem. The separation *can* occur in any
case if the system crashes at the wrong time and you can
find #inode-number named directories in /lost+found.

plan9 folks finessed the problem by not storing the linkcount.
This is why moving a tree is a copy and then rm -rf of the old
location. You win some, you lose some.

Clem wrote:
> Late binding to names (like symlinks) are a dynamic (runtime idea).  Bakul points out that by using the per process u area, the dynamic context can be retained.  The observation is that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm not sure how you keep consistency in the static FS if you don't store the link in the inode.

Symlinks are not a runtime idea but $PWD is strictly a runtime
thing. With symlinks perhaps 4.xBSD took the easy way out by
decreeing that only 8(?) symlink may be traversed at runtime
in interpreting a path for open etc, perhaps to save space but
detecting loops can be done by storing <fsid,inum> per component
and checking that. The same algorithm would help if multiple dir.
hard links were allowed. Sure it has O(n) behavior but the user
pays for it, or you can put a liberal limit on this array.

I don't have much experience with crash recovery on plan9 so
don't know if not having linkcounts is a problem. I haven't
thought through about whether there are crash or concurrency
related issues with allowin arbitray graphs by dir linking.
But probably fixable by writing an intent log ala DBMS.

> At the risk of kicking a dead horse too much 

I think it helps to once in a while wonder about why/how some
system decisions were made and learn something from that; or
gain a deeper understanding. At least that is my excuse!

Thanks for all the responses. My take away is that while it
is possible to allow arbitrary dir links, it would increase
implementation complexity while the added benefit of it are
few if any.