Re: [9fans] mv on directory

Re: [9fans] mv on directory

[Josh Wood]

> I know that. It's a copy, not move.

Looking at mv.c, I believe anything that's not a rename (ie move
within a directory) is a copy, then a hardremove. Mv(1) says the same
thing.


> I just can't see any reason why to mention anything about any bug. I
> didn't do that.
>
>
I wrote that because of this message:

	http://groups.google.com/group/comp.os.plan9/browse_thread/thread/
cfa65300a62de30f

from which I assumed you were extending the list you began there, and
because I support your bug-list idea generally, but *not* as a list
of places where, as I wrote before, "behavior deviates from the
similarly-named command in lunix." It's just boring.

> mkdir dirB
> dircp dirA dirB
> rm -r dirA

It seems like if you made that an rc(1) script and bound it over /bin/
mv, you'd have the desired behavior. No risk would be introduced to
the system, whether or not anyone (aside from the documentation, that
is) relies on mv(1) having the semantics of a wstat.

Given that even if mv(1) agreed to move a directory into another
directory, it would do so as a copy followed by a remove, I don't
understand what benefit there would be in changing mv. It seems like
you're essentially just calling dircp+rm -r by a different name,
which is so easy to do with name spaces.

All that said, it's not like I've never cursed a directory that
wouldn't mv for me in Plan 9 -- so if someone had an answer for Rob's
question: "What should mv do to a tree that resides on multiple file
servers?", it could be interesting to discuss. I don't think arguing
from rm -r is a good tact, though, because of the differing risk
levels between a failed delete and a failed move. One might afford
convenience in the former, and eschew it in the latter.

-Josh

Re: [9fans] mv on directory

[Roman Shaposhnik]

On Nov 1, 2008, at 9:30 AM, Josh Wood wrote:
> All that said, it's not like I've never cursed a directory that
> wouldn't mv for me in Plan 9 -- so if someone had an answer for
> Rob's question: "What should mv do to a tree that resides on
> multiple file servers?", it could be interesting to discuss. I don't
> think arguing from rm -r is a good tact, though, because of the
> differing risk levels between a failed delete and a failed move. One
> might afford convenience in the former, and eschew it in the latter.

That's a very good point. UNIX in general does guarantee certain
things about rename of the
subdirectories within the same FS, but the price they pay in the
kernel and elsewhere
(NFS being the prime example) seems just too high (the original
explanation given by a
friend of mine who wrote this was much more colorful, but I guess guys
like IBM & co. cleaned up
kernel comments quite a bit ;-)):
    http://lxr.linux.no/linux+v2.6.27.4/fs/namei.c#L2479

The behavior of mv(1) as defined by POSIX seems to build on top of the
rename-within-the-same-FS
guarantee, which, in case of Plan9 is not applicable. Thus it would be
an interesting thought
exercise to go over the POSIX text:
     http://www.opengroup.org/onlinepubs/009695399/
and see how much of the required subdirectory move semantics could be
preserved even though
we lack one of the basic building blocks that makes it behave like it
does on UNIX.

Thanks,
Roman.

Re: [9fans] mv on directory

[Roman Shaposhnik]

On Nov 1, 2008, at 7:12 PM, Eric Van Hensbergen wrote:
> On Sat, Nov 1, 2008 at 4:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:
>> On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote:
>>>
>>> I would imagine that 99% of the time (more?) the behavior people
>>> desire would be what you describe.
>>
>> But what is the behavior? Is it literally the above set of rc
>> commands?
>> Or is there an atomicity expectation as well? After dircp dirA dirB
>> the contents of dirB could be surprising, especially given the later
>> rm -r dirA.
>>
>> It seems that mv(1) was taken as far as one could go in terms
>> of having a non-surprising behavior: mv dir1/file  dir2/file is
>> equivalent to cp -x dir1/file dir2/file ; rm dir1/file.
>>
>
> Well, I suppose there'd have to be a bit more wrapping around checking
> for failure of the copy before the erase -- but otherwise perhaps I'm
> being dense and don't see the surprise.

Well, it could be that I'm just too easily surprised. I'll try to
explain. Suppose
that you have the following sequence of directory renames (all within
the single FS
tree):
(1)     /a          ->    /b
(2)     /a/1       ->    /a/2

Because of the POSIX atomicity guarantee the minute you have (1) succeed
your (2) will fail because /a/1 no longer exists. The following, on
the other
hand:
   (1)  mv-dircp /a     /b
   (2)  mv-dircp /a/1 /a/2
is likely to produce /b/2, which, I find surprising. As a side note:
the results
are even more surprising/subtle when renames need to be serialized
in a DSCM. There's been quite a few debates on what DSCM does it
better. Just like Al said -- somebody at UCB had one heck of a trip ;-)

> Its clear you won't get the
> atomicity, but there's no clear way to obtain that -- and, as I said,
> I'm not sure who depends on that when using the mv command.


I would argue that personally I've been conditioned by POSIX to
be able to do:
     $ mv <root of the huge file hierarchy>  .hidden-from-everybody
and expect all references to anything in the original file hierarchy
to fail from that point on.

Thanks,
Roman.

Re: [9fans] mv on directory

[Eric Van Hensbergen]

On Sat, Nov 1, 2008 at 4:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote:
>>
>> I would imagine that 99% of the time (more?) the behavior people
>> desire would be what you describe.
>
> But what is the behavior? Is it literally the above set of rc commands?
> Or is there an atomicity expectation as well? After dircp dirA dirB
> the contents of dirB could be surprising, especially given the later
> rm -r dirA.
>
> It seems that mv(1) was taken as far as one could go in terms
> of having a non-surprising behavior: mv dir1/file  dir2/file is
> equivalent to cp -x dir1/file dir2/file ; rm dir1/file.
>

Well, I suppose there'd have to be a bit more wrapping around checking
for failure of the copy before the erase -- but otherwise perhaps I'm
being dense and don't see the surprise.  Its clear you won't get the
atomicity, but there's no clear way to obtain that -- and, as I said,
I'm not sure who depends on that when using the mv command.

    -eric

Re: [9fans] mv on directory

[Roman Shaposhnik]

On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote:
> On Sat, Nov 1, 2008 at 9:17 AM, Rudolf Sykora
> <rudolf.sykora@gmail.com> wrote:
>>
>>> Again, "What should mv do to a tree that resides on multiple file
>>> servers?"
>>
>> what about: mv dirA dirB ==
>> mkdir dirB
>> dircp dirA dirB
>> rm -r dirA
>>
>> ... if you are able to 'rm -r' (which also may span multiple
>> fileservers) than I don't see any trouble with moving the
>> directories.
>>
>
> I would imagine that 99% of the time (more?) the behavior people
> desire would be what you describe.

But what is the behavior? Is it literally the above set of rc commands?
Or is there an atomicity expectation as well? After dircp dirA dirB
the contents of dirB could be surprising, especially given the later
rm -r dirA.

It seems that mv(1) was taken as far as one could go in terms
of having a non-surprising behavior: mv dir1/file  dir2/file is
equivalent to cp -x dir1/file dir2/file ; rm dir1/file.

Thanks,
Roman.

Re: [9fans] mv on directory

[Eric Van Hensbergen]

On Sat, Nov 1, 2008 at 9:17 AM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
>> There is dircp (in tar(1)) for moving trees around, or the long-form " @{cd
>> fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer.
>
> I know that. It's a copy, not move.
>
>> But "behavior deviates from the similarly-named command in
>> lunix" cannot be the definition of "bug."
>
> I just can't see any reason why to mention anything about any bug. I
> didn't do that.
>
>> Again, "What should mv do to a tree that resides on multiple file servers?"
>
> what about: mv dirA dirB ==
> mkdir dirB
> dircp dirA dirB
> rm -r dirA
>
> ... if you are able to 'rm -r' (which also may span multiple
> fileservers) than I don't see any trouble with moving the directories.
>

I would imagine that 99% of the time (more?) the behavior people
desire would be what you describe.  There are two parts to the
problem: the application and the protocol.  To have the protocol
handle rename of anything other than single element (which may be the
root of a tree) on a single file server is difficult -- however, it
seems perfectly sensible to have the application fall back to the
functionality you describe.  Does anyone rely on the 'mv' command
always having the atomic properties of a wstat?

              -eric

Re: [9fans] mv on directory

[Rudolf Sykora]

> There is dircp (in tar(1)) for moving trees around, or the long-form " @{cd
> fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer.

I know that. It's a copy, not move.

> But "behavior deviates from the similarly-named command in
> lunix" cannot be the definition of "bug."

I just can't see any reason why to mention anything about any bug. I
didn't do that.

> Again, "What should mv do to a tree that resides on multiple file servers?"

what about: mv dirA dirB ==
mkdir dirB
dircp dirA dirB
rm -r dirA

... if you are able to 'rm -r' (which also may span multiple
fileservers) than I don't see any trouble with moving the directories.
Ruda

Re: [9fans] mv on directory

[Josh Wood]

On Nov 1, 2008, at 5:00 AM, 9fans-request@9fans.net wrote:

> I wonder why 'mv' is not allowed to act on directories. I found
> somewhere this argument:
> ----
>>> What should mv do to a `tree' that resides on multiple file servers?
>>> If you can't do something right, sometimes it's not worth doing at
>>> all.
>>>
>>> -rob
>
>
> but this doesn't go well in my ears when put alongside with the
> existence of recursive rm ('rm -r').


There is dircp (in tar(1)) for moving trees around, or the long-form
" @{cd fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer.
Directories in Plan 9 are files. Sometimes synthetic files, unions of
two or more trees. Rob Pike's somewhat gnomic explanation makes
perfect sense, especially if you read about exactly what mv(1) will
and won't do to a directory.

I am 100% behind any effort to uncover bugs and inconsistencies and
make the system better. But "behavior deviates from the similarly-
named command in lunix" cannot be the definition of "bug."

Again, "What should mv do to a tree that resides on multiple file
servers?"


-Josh

[9fans] mv on directory

[Rudolf Sykora]

Hello,

I wonder why 'mv' is not allowed to act on directories. I found
somewhere this argument:
----
What should mv do to a `tree' that resides on multiple file servers?
If you can't do something right, sometimes it's not worth doing at
all.

-rob
----

but this doesn't go well in my ears when put alongside with the
existence of recursive rm ('rm -r').

Thanks
Ruda Sykora