From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Douglas A. Gwyn" <DAGwyn@null.net>
Message-ID: <3BC13A42.7FE9178C@null.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <20011007162401.77DEE1998A@mail.cse.psu.edu>, <20011008062832.V28720@cackle.proxima.alt.za>
Subject: Re: [9fans] mv vs cp
Date: Mon,  8 Oct 2001 09:50:27 +0000
Topicbox-Message-UUID: 01ba3dca-eaca-11e9-9e20-41e7f4b1d025

Lucio De Re wrote:
> There are really only two social factors overriding here.  People
> like me have grown to expect it, unfortunate as it may be, and the
> alternative is inconsistent and open to error, besides being much
> more time and resource intensive.

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).

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).

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.

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