From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14209 invoked from network); 29 Dec 2021 21:00:26 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 29 Dec 2021 21:00:26 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 341F79CF27; Thu, 30 Dec 2021 07:00:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0EDF69CEA9; Thu, 30 Dec 2021 07:00:10 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PE8z1S4g"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C7E5B9CEA9; Thu, 30 Dec 2021 07:00:08 +1000 (AEST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 4AE0A9CE9F for ; Thu, 30 Dec 2021 07:00:08 +1000 (AEST) Received: by mail-pg1-f170.google.com with SMTP id i8so10933956pgt.13 for ; Wed, 29 Dec 2021 13:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CDygEaOmmHPwMNUipa7MdT36aQD5rvf54tddKTHN2pM=; b=PE8z1S4gTeSLnk+PLogu0GzNWMjYT+B4h6r1igjFruoQz9uHaPtVcNC9Ov3sD1Rqqq DNvoLnA9Ovfmh0+WrjJ3KOpBsI8Avkts00wDW+pjamXctVh2Wd5mhQtNG2g+QD51ML4f 98zCBpGrH5AwlZ6sFCfWmGYzoZp9r7h8i/8+hmj+AWhRYz6HzkvbHLRcXT2qGZ1o2PSa gMTPy3gf/BI8AK6y/vtmDQwyhDyIWbjkQ7iDsNrAqe7QRdecRXJm+SK6i4CA07lUfphy m3IqEubxqkz9obUi6NCjBPrqqO2d4iIa5/41xfFhzrYMFkjzoWeDawz+9vHIDhOcixO3 GU7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CDygEaOmmHPwMNUipa7MdT36aQD5rvf54tddKTHN2pM=; b=bLKYkqS4S7zStMbf2CVoTTG0cQc7tqrH+9m6e22JDnmS8I6GuMnu0HVRguGfy7P+oq T5V+C4ALhUkvtLYLvIR201KgbOskrJE+bUSUpUMcY/gAKmnrPZdihf5SIHLVX5xzQ++x VMnNP9GhNs8CCUd7OgcxKEAsEFjLo6kiEZbvgYUIjta7RmqmHfPD21AYnjpKuJmNJVOm qGUWYfIeavfno7TK95YRRzftJ6HhobEdLGtFmmEpaZUex/40hSKGOekKgrrYqSn8blhK zF9rbn91C40sQTj8UDg1gqYVoL3HKZjCbJPG7GGOwOE2xYwI7BEpXGL0gVK/0HuxDl91 cqiw== X-Gm-Message-State: AOAM532MmGdUYH1PPAga5A44Q6SCelPllwm1oDHFEe1rcG6CgIAkiL2k IQnNY1woX4PWpHfEeTFJ/spZ0gM6lpce5LRztM0= X-Google-Smtp-Source: ABdhPJzEKrboDQX+CipUF9/7n7l3+yW62Lrg+XtDT4+oU/ujPYgxL+cH1jyNazjeWZHlVL9nWBVujgwD/7MkXOUqBFw= X-Received: by 2002:a65:6819:: with SMTP id l25mr25117885pgt.255.1640811607563; Wed, 29 Dec 2021 13:00:07 -0800 (PST) MIME-Version: 1.0 References: <202112291714.1BTHEiXo008223@freefriends.org> In-Reply-To: From: Rob Pike Date: Thu, 30 Dec 2021 07:59:56 +1100 Message-ID: To: ron minnich Content-Type: multipart/alternative; boundary="0000000000000321ae05d44f399b" Subject: Re: [TUHS] moving directories in svr2 X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "bakul@iitbombay.org" , "tuhs@minnie.tuhs.org" Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000000321ae05d44f399b Content-Type: text/plain; charset="UTF-8" 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. > > > --0000000000000321ae05d44f399b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not an answer, but relevant: Apple's Time Machine work= s by hard-linking directories to make the forest of old roots.

-rob


On Thu, Dec 30, 2021 at 5:28 AM ron minnich= <rminnich@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@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 thre= ad. Sorry)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--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
>
>=C2=A0 =C2=A0 =C2=A0 TAR(1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TA= R(1)
>
>=C2=A0 =C2=A0 =C2=A0 NAME
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tar, dircp - archiver
>
>=C2=A0 =C2=A0 =C2=A0 SYNOPSIS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tar key [ file ... ]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dircp fromdir todir
>
>=C2=A0 =C2=A0 =C2=A0 DESCRIPTION
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tar saves and restores file tr= ees.=C2=A0 It is most often used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport a tree of files from= one system to another.=C2=A0 The
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and .tz.=C2=A0 = If no extension matches, gzip is used.=C2=A0 The z
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flag is unneces= sary (but allowed) when using the t and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 x verbs on arch= ives with recognized extensions.
>
>=C2=A0 =C2=A0 =C2=A0 EXAMPLES
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tar can be used to copy hierar= chies thus:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 @{cd fromdir &a= mp;& tar c .} | @{cd todir && tar xT}
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dircp does this.
>
>=C2=A0 =C2=A0 =C2=A0 SOURCE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/sys/src/cmd/tar.c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/rc/bin/dircp
>
>=C2=A0 =C2=A0 =C2=A0 SEE ALSO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ar(1), bundle(1), tapefs(4), m= kfs(8)
>
>
>
> cessna%
> > On Dec 29, 2021, at 12:38 PM, Clem Cole <clemc@ccc.com> wrote:
> >
> > At the risk of kicking a dead horse too much ...
> >
> > On Wed, Dec 29, 2021 at 12:14 PM <arnold@skeeve.com> wrote:
> > Plan 9 eventually did something like this. I don't remember t= he details.
> > Arnold - point taken but ... unfortunately, I think that the comp= arison is a little difficult because Plan9's concepts of namespaces is = a tad different than UNIX's.=C2=A0 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.=C2= =A0 Links were (are) also a static concept.=C2=A0 =C2=A0Late binding to nam= es (like symlinks) are a dynamic (runtime idea).=C2=A0 Bakul points out tha= t by using the per process u area, the dynamic context can be retained.=C2= =A0 The observation is that .. (like symlinks) tend to be a runtime (dynami= c) notion, although I'm not sure how you keep consistency in the static= FS if you don't store the link in the inode.=C2=A0 As someone that did= , I suggest - try writing fsck if you are using dynamic content.=C2=A0 =C2= =A0How do you know?=C2=A0 I'd still claim it is the same issue.
> >
> > Anyway, I suppose that like context sensitive symlinks (which I s= orely miss), you could do this and keep a list of the N inodes for the N pa= rents 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.
>
--0000000000000321ae05d44f399b--