Re: [9fans] mv vs cp

[presotto@closedmind.org]

There are a number of solutions being aired here:

1) avoiding a copy the data and perhaps some of the metadata
2) on a recursive call, avoiding a message per file
3) getting it right if two people/programs do it simultaneously

The first 2 are performance, the last is adding something that
you can't do with our current mv.

(3) seems to be a solving a problem in the wrong place.
If two people simultaneously move a graph, the result is going to
be confusing/scarey even if everything resides in the same file
server and we somehow manage to lock the whole file server while
it happens, since in the absolute best case one is going to see
his graph inexpicably disappear.  This is more a social problem than
a technical one.  If programs are going to do it, they'ld better
set locks somewhere and have some agreement on what name space is
being looked at.

In plan 9, as rob pointed out, there's no way
for the file server to know what your name space is.
Therefore, the application or kernel has to walk the whole
subspace being moved and then try to create a set of requests
to the relevant file servers.  Not only will this set not 
be locked but you'll have done a large amount of walking
to figure out what to do.  Because of this, I think we're stuck with
forgetting about (2) and (3) without majorly changing how mounts
work.

(1), on the otherhand, may be possible.  It still requires that
you walk both paths and make sure they end up on the same
server.  Then you can have a message that says 'mv fid1 to fid2'.
I think that that's the best you can do, i.e., file by file.
You might improve that to a directory mv but you'ld have to
know that nothing was mounted below the source directory.
That is probably more trouble than its worth.

The file server can always say 'error - unimplemented' and
you can fall back to the create/copy/rm.  That way you
don't have to require exportfs, ftpfs, upas/fs and a
slurry of other impossible to understand servers to
change.

By the way, think about the following scenario:

	mkdir x
	> x/y
	bind -a x .
	mv y z

What do you want to happen here?  Should y change directory when
renamed to z or not?

On the whole, I don't think it worth the trouble.  As the above
example points out, the result of mv is already pretty confusing
in our namespace.  Whatever solution you choose should make things
less confusing, not more.