30 Dec
2021
30 Dec
'21
1:33 a.m.
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
30 Dec
30 Dec
9:40 a.m.
New subject: moving directories in svr2
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
1088
days inactive
1089
days old
1 comments
2 participants
participants (2)
-
Jay Logue -
jnc＠mercury.lcs.mit.edu