Re: [9fans] mv on directory

[Josh Wood <josh@utopian.net>]

> 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