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=MAILING_LIST_MULTI
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 9827 invoked from network); 30 Dec 2021 03:45:44 -0000
Received: from minnie.tuhs.org (45.79.103.53)
  by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2021 03:45:44 -0000
Received: by minnie.tuhs.org (Postfix, from userid 112)
	id BA0A59CFF5; Thu, 30 Dec 2021 13:45:41 +1000 (AEST)
Received: from minnie.tuhs.org (localhost [127.0.0.1])
	by minnie.tuhs.org (Postfix) with ESMTP id 262419CD62;
	Thu, 30 Dec 2021 13:45:17 +1000 (AEST)
Received: by minnie.tuhs.org (Postfix, from userid 112)
 id B4A0F9CD62; Thu, 30 Dec 2021 13:45:15 +1000 (AEST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
 by minnie.tuhs.org (Postfix) with ESMTPS id AEB939CC2E
 for <tuhs@minnie.tuhs.org>; Thu, 30 Dec 2021 13:45:13 +1000 (AEST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
 id B9B3718C08E; Wed, 29 Dec 2021 22:45:12 -0500 (EST)
To: tuhs@minnie.tuhs.org
Message-Id: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu>
Date: Wed, 29 Dec 2021 22:45:12 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
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 <tuhs.minnie.tuhs.org>
List-Unsubscribe: <https://minnie.tuhs.org/cgi-bin/mailman/options/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=unsubscribe>
List-Archive: <http://minnie.tuhs.org/pipermail/tuhs/>
List-Post: <mailto:tuhs@minnie.tuhs.org>
List-Help: <mailto:tuhs-request@minnie.tuhs.org?subject=help>
List-Subscribe: <https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=subscribe>
Cc: jnc@mercury.lcs.mit.edu
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

    > From: Bakul Shah

    > My guess is *not* storing a path instead of a ptr to the inode was done
    > to save on memory.

More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads.

    > Every inode has a linkcount so detecting when the last conn. is severed
    > not a problem.

Depends; if a directory _has_ to be empty before it can be deleted, maybe; but
if not, no. (Consider if /a/b/c/d exists, and /a/b is removed; the tree
underneath it has to be walked and the components deleted. That could take a
while...) In the general case (e.g. without the restriction to a tree), it's
basically the same problem as garbage collection in LISP.

	  Noel