Re: [9fans] mv vs cp

[Lucio De Re <lucio@proxima.alt.za>]

On Mon, Oct 08, 2001 at 09:50:27AM +0000, Douglas A. Gwyn wrote:
> 
> We should be careful to distinguish between a utility command,
> which usually is best if it works as widely as it can to do a
> simply described function (from the user point of view; it might
> be complicated to implement), and a fundamental operation in the
> protocol itself (I/O primitive).
> 
With the principle of least surprise applying here.  Mv copying only
one layer of files is in breach of it, in my opinion.

> I think it is reasonable for the 9P200x protocol to have a
> Trename request, which of course can fail if the operation is
> not possible or makes no sense for the particular object.
> Then it is up to the (file) server to make it happen; the
> important thing is that the file server need only use local
> locks while it shuffles things around (if precached, it could
> be serviced as an atomic operation).
> 
I think there's growing agreement on this score.  I certainly feel
it's justified.  But Jim's reservations about race conditions have to
be taken into account.  Alexander seems to think BSD did it wrong (did
Linux improve on that?) but didn't suggest it can't be done.

> There is the question of what permissions should be required
> for a rename to succeed: write access on the directory, and/or
> on the named object itself?  This may be the same question as
> whether the rename ought to be for a handle in the directory
> (i.e. Trename is an operation on a directory) or for a handle
> on the named object.
> 
These are rules, they need to be established and documented (and make
sense, of course).  But that's about it, really.

> I am inclined to think rename ought to work within a directory
> but not in general between distinct path prefixes.

My choice would be the point where copying the data becomes necessary.
Whatever operation doesn't need to relocate the actual file contents,
ought to succeed.  But I can't say I understand all the subtleties
involved.

++L