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
