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=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6348 invoked from network); 30 Dec 2021 03:16:25 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2021 03:16:25 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A8B2B9CF8A; Thu, 30 Dec 2021 13:16:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 06C589CD62; Thu, 30 Dec 2021 13:15:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=iitbombay-org.20210112.gappssmtp.com header.i=@iitbombay-org.20210112.gappssmtp.com header.b="aG1Xc+1P"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 130AD9CD62; Thu, 30 Dec 2021 13:15:45 +1000 (AEST) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by minnie.tuhs.org (Postfix) with ESMTPS id EACEE9CC2E for ; Thu, 30 Dec 2021 13:15:42 +1000 (AEST) Received: by mail-ot1-f47.google.com with SMTP id 35-20020a9d08a6000000b00579cd5e605eso30737925otf.0 for ; Wed, 29 Dec 2021 19:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=p3tCJeUsJRfe4U3PGgJd5bCXquuF2zlZk1MLY2ZoQOQ=; b=aG1Xc+1P9t/9s91CRLMcEXYQIg7Ydlq9RpI/qdALJbkGEU4+QI1tYPx+UfDy89DzJ+ xj8cnoA0/5r7H43xUI1G+GmNn4DrZxjWvJBlXXOknLjrAwWXF9jK2agGEVGthcd3smaG J4xgoWcynUhT+4B0wkKzbcl67NPAtf6vXNFsSwltdBsgnqFAC3TiZ4LQS4xoYzUmvRZj E+OGKaJ+xVR90p7tNQIMfissio41NaTV6pOXlo3XlxR+4MXfJwR7/m98psW5dnazec+w gznoDKXlbh9FuIiaaiYBiIXm9JhO6mKm/ci5jp9hVnGHq/kdE0J3RnG82y8p5LWRMNYP I9Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=p3tCJeUsJRfe4U3PGgJd5bCXquuF2zlZk1MLY2ZoQOQ=; b=djoolVNTVP6GkzkX/cX2aeK70oS7N1n+LzHEGpw5FP0Q6y82x+DzJT+/qt78eIye6T DFxpUqDILS6dBpcVDd3og6N6Odq2aeGcJmrniGv27vHdp9FAMQB/ITk38aIp3EggnDPs d0kZWj4qLGq9Ku6Rg9TmLOuBOjTgACjcaifzoXcU5cjxsUlPLm/ZcCa4anpI8eF0iBCK dtwy7D0kuAuRJkEmfwfIF55l8HOahIzRAHbfLR6n/aP8nLSkslWOfm9SKBw0SEo2Nd7N 8wxYUvomchJTweElkBX/Xj1wY0OqkNsklrxFY0E07Y0R1cFDKdlyiogBAEPHX4fdUn66 8MtA== X-Gm-Message-State: AOAM532+kNWTrl6YgLdzakdX29Af6ZC4Os3ML5jYAqfnzzmgHRvNoSwM eJ8CKnaAkhs/er5+RdCZnQejZ800agjCRA== X-Google-Smtp-Source: ABdhPJzxv776+PdLO+1hBMsPWmJlYphvLc6MdMe/ayLr+lHwcUtdyVzPqmQpKiPkRdB5DWwy5/rtkg== X-Received: by 2002:a05:6830:14ce:: with SMTP id t14mr19847474otq.46.1640834141719; Wed, 29 Dec 2021 19:15:41 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id o145sm4102215ooo.1.2021.12.29.19.15.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Dec 2021 19:15:41 -0800 (PST) From: Bakul Shah Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Wed, 29 Dec 2021 19:15:39 -0800 References: To: TUHS main list In-Reply-To: Message-Id: <5467120F-A6D0-4882-A577-CB612321402E@iitbombay.org> X-Mailer: Apple Mail (2.3693.40.0.1.81) 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > On Dec 29, 2021, at 12:42 PM, Richard Salz = wrote: >=20 > https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with: >=20 > Each directory always has at least two entries. The > name "." in each directory refers to the directory itself. Thus a > program may read the current directory under the name =E2=80=9C.=E2=80=9D= > without knowing its complete path name. The name =E2=80=9C..=E2=80=9D = by > convention refers to the parent of the directory in which it > appears, that is, to the directory in which it was created. > The directory structure is constrained to have the form > of a rooted tree. Except for the special entries =E2=80=9C.=E2=80=9D = and =E2=80=9C..=E2=80=9D, Note that "." or ".." entries are not needed if you store the entire path of the current working dir. in a process'es kernel state. My guess is *not* storing a path instead of a ptr to the inode was done to save on memory. > each directory must appear as an entry in exactly one other, > which is its parent. The reason for this is to simplify the > writing of programs which visit subtrees of the directory > structure, and more important, to avoid the separation of > portions of the hierarchy. If arbitrary links to directories > were permitted, it would be quite difficult to detect when > the last connection from the root to a directory was severed Every inode has a linkcount so detecting when the last conn. is severed not a problem. The separation *can* occur in any case if the system crashes at the wrong time and you can find #inode-number named directories in /lost+found. plan9 folks finessed the problem by not storing the linkcount. This is why moving a tree is a copy and then rm -rf of the old location. You win some, you lose some. Clem wrote: > 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. Symlinks are not a runtime idea but $PWD is strictly a runtime thing. With symlinks perhaps 4.xBSD took the easy way out by decreeing that only 8(?) symlink may be traversed at runtime in interpreting a path for open etc, perhaps to save space but detecting loops can be done by storing per component and checking that. The same algorithm would help if multiple dir. hard links were allowed. Sure it has O(n) behavior but the user pays for it, or you can put a liberal limit on this array. I don't have much experience with crash recovery on plan9 so don't know if not having linkcounts is a problem. I haven't thought through about whether there are crash or concurrency related issues with allowin arbitray graphs by dir linking. But probably fixable by writing an intent log ala DBMS. > At the risk of kicking a dead horse too much=20 I think it helps to once in a while wonder about why/how some system decisions were made and learn something from that; or gain a deeper understanding. At least that is my excuse! Thanks for all the responses. My take away is that while it is possible to allow arbitrary dir links, it would increase implementation complexity while the added benefit of it are few if any.=