Not an answer, but relevant: Apple's Time Machine works by hard-linking directories to make the forest of old roots. -rob On Thu, Dec 30, 2021 at 5:28 AM ron minnich wrote: > 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 > wrote: > > > > Plan 9 can't move directories with mv. I will only change the name of > them. > > (If this is the question. I was only half paying attention to the > thread. Sorry) > > > > --bwc > > > > cessna% mkdir dira > > cessna% mkdir dirb > > cessna% touch dira/a > > cessna% touch dirb/b > > cessna% mv dira dirb > > mv: can't remove ./dirb: remove -- directory not empty > > > > To move contents of directories we use dircp. > > > > cessna% man dircp > > > > TAR(1) TAR(1) > > > > NAME > > tar, dircp - archiver > > > > SYNOPSIS > > tar key [ file ... ] > > > > dircp fromdir todir > > > > DESCRIPTION > > Tar saves and restores file trees. It is most often used to > > transport a tree of files from one system to another. The > > > > ... > > and .tz. If no extension matches, gzip is used. The z > > flag is unnecessary (but allowed) when using the t and > > x verbs on archives with recognized extensions. > > > > EXAMPLES > > Tar can be used to copy hierarchies thus: > > > > @{cd fromdir && tar c .} | @{cd todir && tar xT} > > > > Dircp does this. > > > > SOURCE > > /sys/src/cmd/tar.c > > /rc/bin/dircp > > > > SEE ALSO > > ar(1), bundle(1), tapefs(4), mkfs(8) > > > > > > > > cessna% > > > On Dec 29, 2021, at 12:38 PM, Clem Cole wrote: > > > > > > 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. > > >