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,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21315 invoked from network); 29 Dec 2021 18:27:57 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 29 Dec 2021 18:27:57 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5FD7B9CFE8; Thu, 30 Dec 2021 04:27:55 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 917319CEBE; Thu, 30 Dec 2021 04:27:28 +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="VFlnJLG6"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1A4FB9CEBE; Thu, 30 Dec 2021 04:27:26 +1000 (AEST) Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 7FF419CEA9 for ; Thu, 30 Dec 2021 04:27:25 +1000 (AEST) Received: by mail-oo1-f52.google.com with SMTP id t9-20020a4a8589000000b002c5c4d19723so7210619ooh.11 for ; Wed, 29 Dec 2021 10:27:25 -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:content-transfer-encoding; bh=4A6ngCJQNOCQlgHAdMhuTo+lfo9a7Q88SkVvHxxS6WU=; b=VFlnJLG6Z0K1g7oKKBUgJT0iQIwVzeSlPiM7CEQW/FphVARLMLq+LedgWR5/dlIAf0 tDCPWG8tRDfg1uY3RYrVmMCQfrUQwcKRILH4CmlbpDhRQg85IZhJJqe6Z8z78sbPgMBn neYFe+lU8LZbT7yfHKExcIKA0bIQjyJwoomyhcEwjB36d558EDDB56eScLgRaaVRUoC3 jqU3KCRDLLxb4yvxS8oy86PZBLBLS1pHHSks46TP1R/BqdBLzluK7vcTaexdEQPQ17q6 dwqskPCEtLPXmCOQW8+d6+ECHEvHDJlG0CSVDU0F1wZq6subelzuRhHCPbNQ3l3Ks2Zr O4fw== 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:content-transfer-encoding; bh=4A6ngCJQNOCQlgHAdMhuTo+lfo9a7Q88SkVvHxxS6WU=; b=UMsHFxa5KOvKHC4Ygb6snYY3ViWn1GscZXBIZPDka+uKIkKJuWHt6H9Hc3z+6GZoV3 4gnzQsOZMJQXB9FZOQdDNV3QtvGX9eCkphxGC7YRg4ovO434D3Da/YQrgzv6oYYlhpb2 aRS8qMyyjPGEjgBvUP+q+g+ityV7P28vf8+eg3LXKvin19wGapF0AdCMLIhTPhWTd9iY PBt0riNL1Ab0QtspzURe155XaG6muNAPAVgwZwekVesfL/xo6k0XRsGklniJ4hwbQwA3 Bc89zGLXKw2KIt534B8alNGi3/LRWCnzC+7FE6520eklTbaGh1I9NkDPxLUbKe3nFwpj hd6g== X-Gm-Message-State: AOAM531PaPxvb/lQxyk45caI69QNz63FQzPB15DKnO4H+1dhS+iaqzYx tyTED1d6WePKwIfLQ8SvbZrs9HgffbIueCSgW4o= X-Google-Smtp-Source: ABdhPJyMF69t9Jp8XmRn9ZsjejNj3sie/IzKyQGhr7zhGPiJ8wT/FWOcv5brYXLBGDFs3yXacrsc/Jc+P2RAVnJxfkg= X-Received: by 2002:a4a:3e8d:: with SMTP id t135mr17444881oot.78.1640802443192; Wed, 29 Dec 2021 10:27:23 -0800 (PST) MIME-Version: 1.0 References: <202112291714.1BTHEiXo008223@freefriends.org> In-Reply-To: From: ron minnich Date: Wed, 29 Dec 2021 10:27:12 -0800 Message-ID: To: Brantley Coile Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" since .. came up, nobody mentioned it yet, https://plan9.io/sys/doc/lexname= s.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 the= m. > (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 diff= erent than UNIX's. But I'll let Rob or Ken comment as they lived and devel= oped both systems. > > > > FWIW: An object store is something that retains information after the p= rocesses that operates on it complete - i.e. its a static entity. Links we= re (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 .. (l= ike 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 th= e inode. As someone that did, I suggest - try writing fsck if you are usin= g 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 th= at .. picks the proper one on the way out and you can still have the static= notion which something like fsck can check off line. >