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 <rminnich(a)gmail.com> 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 <brantley(a)coraid.com>
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 <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.