[TUHS] moving directories in svr2

[Jay Logue]

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 
<https://github.com/jaylogue/retro-fuse/blob/b300865c1aa4c38930adea66de364f182c73b3b5/src/v6fs.c#L599>].  
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211229/258bdafd/attachment.htm>