29 Dec
2021
29 Dec
'21
11:38 p.m.
At the risk of kicking a dead horse too much ...
On Wed, Dec 29, 2021 at 12:14 PM <arnold(a)skeeve.com> 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.