On Dec 29, 2021, at 12:38 PM, Clem Cole <clemc(a)ccc.com> wrote: 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.

since .. came up, nobody mentioned it yet, https://plan9.io/sys/doc/lexnames.pdf but the subject line is "moving directories" and, as pointed out, on old school file systems with hard links, it's not a move, just an ln, more or less. And in the easy case, it's easy; and in the not so easy case, it can be impossible ... On newer systems, which don't have such notions as hard links, it's a different game, and on many, it may not be possible; dircp to the rescue, with all the pain that implies (doesn't go well when you are in CA and the server is in NJ, trust me :-) But this brings up a question I forgot: what was the last Unix version that let users make arbitrary links, such that the file system was no longer a DAG? I recall in v6 days hearing that earlier Unix allowed this, and that cleanup (via icheck and friends) got to be near impossible. On Wed, Dec 29, 2021 at 9:50 AM Brantley Coile <brantley(a)coraid.com> wrote: them. thread. Sorry) details. 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. 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. 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.