At the risk of kicking a dead horse too much ...

On Wed, Dec 29, 2021 at 12:14 PM <> wrote:
Plan 9 eventually did something like this. I don't remember the details.
Arnold - point taken but ... unfortunately, I think that the comparison is a little difficult because Plan9's concepts of namespaces is a tad different than UNIX's.  But I'll let Rob or Ken comment as they lived and developed both systems.

FWIW: An object store is something that retains information after the processes that operates on it complete - i.e. its a static entity.  Links were (are) also a static concept.   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.  As someone that did, I suggest - try writing fsck if you are using dynamic content.   How do you know?  I'd still claim it is the same issue.

Anyway, I suppose that like context sensitive symlinks (which I sorely miss), you could do this and keep a list of the N inodes for the N parents and then like CDSL's keep the one you used to get there in the u area so that .. picks the proper one on the way out and you can still have the static notion which something like fsck can check off line.