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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FORGED_MUA_MOZILLA,HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 10155 invoked from network); 30 Dec 2021 03:48:27 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2021 03:48:27 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 3D02B9CFAF; Thu, 30 Dec 2021 13:48:25 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A60899CD62; Thu, 30 Dec 2021 13:48:07 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=toaster.com header.i=@toaster.com header.b="gInl/p0v"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6CC299CD62; Thu, 30 Dec 2021 13:48:05 +1000 (AEST) X-Greylist: delayed 423 seconds by postgrey-1.36 at minnie.tuhs.org; Thu, 30 Dec 2021 13:48:01 AEST Received: from outpost.toaster.com (outpost.toaster.com [164.90.156.247]) by minnie.tuhs.org (Postfix) with ESMTPS id E7C359CC2E for ; Thu, 30 Dec 2021 13:48:01 +1000 (AEST) Received: from [192.168.44.247] (static-47-181-10-112.lsan.ca.frontiernet.net [47.181.10.112]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: jay) by outpost.toaster.com (Postfix) with ESMTPSA id 0669417A298 for ; Thu, 30 Dec 2021 03:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toaster.com; s=default; t=1640835658; bh=Onj1DNYsy653m+NfxacFetwyHwxG/Pd19JDFvNfLZls=; h=Date:From:Subject:To:References:In-Reply-To:From; b=gInl/p0vUNzvA7oRzziTnhjKQku/3LyLfI613WbDYhb3wHcdQLZTt2SaISJeNGJ3F v3kHURldYM2WOJ2+5dYqElahmLDwLaIkeooN9RVDy/GLTd7SrklLuepMCBd9xPx7om 0MS27OSHQrnIEZ6hXiKJa3ZWva8qlNkO1zn/uoOoLoSFaOkI0iHQYQ6sxupZDPNkwH KLsS6aeooanA3suoYSKxv0et9JGABZxVMYpwQDapuTX4eaOvWKksRR4aXjBSeTZkEE foqTr/+nMw+7TDsMjW+fR53H9uJ7RlyoDrYjDWEsdC/HvEQaI0VIBehT8eoap6Aaxg fBmHtmtMCiUVw== Content-Type: multipart/alternative; boundary="------------PNwNX7UeOpHwPD46hGzcQLZK" Date: Wed, 29 Dec 2021 19:40:57 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: tuhs@minnie.tuhs.org References: <20211229193348.A4ED018C08E@mercury.lcs.mit.edu> Content-Language: en-US In-Reply-To: <20211229193348.A4ED018C08E@mercury.lcs.mit.edu> Message-Id: <20211230034805.6CC299CD62@minnie.tuhs.org> 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: , From: Jay Logue via TUHS Reply-To: Jay Logue Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------PNwNX7UeOpHwPD46hGzcQLZK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit v6 mv is indeed limited to renaming directories.  However, mv on v7 is able to move directories. Considering the similarity between the code bases, I think it would be fairly straightforward to support directory move on v6 in the same manner as was done in v7.  (On a related tangent, I found it fairly straightforward to implement modern rename(2) semantics on top of both code bases in my retro-fuse filesystem [e.g. v6fs.c:559 ].  Of course I had the benefit of a single-threaded execution environment.) Given the way mkdir and directory renaming worked in v6/v7, I'm not sure the lack of atomicity in directory move would have made things any worse for operators. It's interesting though that dcheck does not look for malformed directory links. --Jay On 12/29/2021 11:33 AM, Noel Chiappa wrote: > > From: Clem Cole > > > Try it on V6 or V7 and you will get 'directory exists' as an error. > > The V6 'mv' is prepared to move a directory _within_ a directory (i.e. > 'rename' functionality). I'm not sure why it's not prepared to move within > a partition; probably whoever wrote it wasn't prepared to deal with all the > extra work for that (unlink from the old '..', then link to the '..' in the > new directory, etc, etc). > > (The MIT PWB1 had a 'mvdir' written by Jeff Schiller, so PWB1 didn't have > 'move directory' functionality before that. MIT must have been using the PWB1 > system for 6.031, which I didn't recall; the comments in 'mvdir' refer to it > being used there.) > > The V6 'mv' is fairly complicated (as I found out when I tried to modify it > to use 'smdate()', so that moving a file didn't change its 'last write' > date). Oddly enough, it is prepared to do cross-partition 'moves' (it forks a > 'cp' to do the move). Although on V6, 'cp' only does one file; 'cp *.c > {dest}' was not supported, there was 'cpall' for that. (Why no 'mvall', I > wonder? It would have been trivial to clone 'cpall'.) > > Run fact; the V6 'mv' is the place that has the famous (?) "values of B will > give rise to dom!" error message (in the directory-moing section). > > > if the BSD mv command for 4.1 supported it. If it did then it was not > > atomic -- it would have had to create the new directory, move the > > contents independently and then remove the old one. > > Speaking of atomic operation, in V6 'mkdir' (not being a system call) was > not atomic, so if interrupted at 'just the right time', it could leave > the FS in an inconsistent state. That's the best reason I've come across > to make 'mkdir' a system call - it can be made atomic that way. > > Noel --------------PNwNX7UeOpHwPD46hGzcQLZK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
v6 mv is indeed limited to renaming directories.  However, mv on v7 is able to move directories.  Considering the similarity between the code bases, I think it would be fairly straightforward to support directory move on v6 in the same manner as was done in v7.  (On a related tangent, I found it fairly straightforward to implement modern rename(2) semantics on top of both code bases in my retro-fuse filesystem [e.g. v6fs.c:559].  Of course I had the benefit of a single-threaded execution environment.)

Given the way mkdir and directory renaming worked in v6/v7, I'm not sure the lack of atomicity in directory move would have made things any worse for operators. It's interesting though that dcheck does not look for malformed directory links.

--Jay

On 12/29/2021 11:33 AM, Noel Chiappa wrote:
    > From: Clem Cole

    > Try it on V6 or V7 and you will get 'directory exists' as an error.

The V6 'mv' is prepared to move a directory _within_ a directory (i.e.
'rename' functionality). I'm not sure why it's not prepared to move within
a partition; probably whoever wrote it wasn't prepared to deal with all the
extra work for that (unlink from the old '..', then link to the '..' in the
new directory, etc, etc).

(The MIT PWB1 had a 'mvdir' written by Jeff Schiller, so PWB1 didn't have
'move directory' functionality before that. MIT must have been using the PWB1
system for 6.031, which I didn't recall; the comments in 'mvdir' refer to it
being used there.)

The V6 'mv' is fairly complicated (as I found out when I tried to modify it
to use 'smdate()', so that moving a file didn't change its 'last write'
date). Oddly enough, it is prepared to do cross-partition 'moves' (it forks a
'cp' to do the move). Although on V6, 'cp' only does one file; 'cp *.c
{dest}' was not supported, there was 'cpall' for that. (Why no 'mvall', I
wonder? It would have been trivial to clone 'cpall'.)

Run fact; the V6 'mv' is the place that has the famous (?)  "values of B will
 give rise to dom!" error message (in the directory-moing section).

    > if the BSD mv command for 4.1 supported it. If it did then it was not
    > atomic -- it would have had to create the new directory, move the
    > contents independently and then remove the old one.

Speaking of atomic operation, in V6 'mkdir' (not being a system call) was
not atomic, so if interrupted at 'just the right time', it could leave
the FS in an inconsistent state. That's the best reason I've come across
to make 'mkdir' a system call - it can be made atomic that way.

	Noel

--------------PNwNX7UeOpHwPD46hGzcQLZK--