strange interaction between open and cwd

[Grant Edwards]

On 2010-05-04, Cameron Simpson <cs at zip.com.au> wrote:
> On 03May2010 15:23, Baz Walter <bazwal at ftml.net> wrote:

>| so "here" must always be available somehow, even if getcwd() fails
>
> Well, yeah. Just like an open file handle on a file you have
> subsequently removed still exists. Remember that the directory tree
> is a digraph, and (historically at least, and probably for real in
> many filesystems) '.' and '..' are just pointers to "here" and "up".
>
> Your rmdir has detached the current directory from the one that was
> "up", but the "up" pointer still references the old parent.
>
> There's just no filesystem path that refers to your current directory
> any more (except '.'). Just like a detached object in python really.

Indeed.  In fact, CPython uses a pointer/link and reference counting
scheme that's pretty much identical to that used by Unix filesystems
except that Python objects can form a generalized graph, and Unix
filesystems are constrained to be a tree.

Though once upon a time SunOS allowed you to create arbitrary graphs
within a filesystem by allowing you to create hard links to
directories.  You had to be root, and you had to use some sort of
override option on the command line (probably -f).  If you knew enough
to gracefully extract yourself from the situation, you probably
wouldn't have done it in the first place.  IOW, it wasn't something
one did a second time.

Still, at the time, it _seemed_ like a good way to share a directory
of source code amongst multiple projects.  I don't remember why
symlinks wouldn't accomplish the task -- something to do with RCS...

-- 
Grant