- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 27 Jan 2000 23:56:05 -0500
- To: w3c-dist-auth@w3.org
From: Yaron Goland <yarong@Exchange.Microsoft.com>
The last paragraph of section 8 reads: "Although [WebDAV] allows a MOVE on a
collection to be a non-atomic operation, the MOVE operation defined here
MUST be atomic. Even when the Request-URI identifies a collection, the MOVE
operation involves only removing one binding to that collection and adding
another. There are no operations on bindings to any of its children, so the
case of MOVE on a collection is the same as the case of MOVE on a
non-collection resource. Both are atomic."
As there is no way to tell the difference between a URI that was mapped
through a BIND method and a URI that was mapped through a MKCOL the effect
of this paragraph is to re-write RFC 2518 to make MOVE atomic.
Agreed.
The issue
here is largely a repeat of the issues addressed in Yaron.AtomicDelete.
Not really. As you point out in the AtomicDelete thread, unlike
DELETE, MOVE is atomic in the NT (and all Unix) file systems,
as long as you stay in the same file volume/partition/whatever.
So the real question is whether the server should automatically
turn a MOVE into a COPY/DELETE (which is harder to make atomic),
or should it fail the MOVE and let the client decide whether it
wants to simulate the MOVE with a COPY/DELETE.
An argument for saying that the client should decide (and not
have the server automatically do it), is that a COPY/DELETE is
often significantly different from a "real" MOVE wrt bindings
(e.g. hard links), ACL's, cost of the operation, and other issues.
A client may of course present the:
MOVE else { COPY; DELETE }
sequence as a single logical operation to its user, but that should
be a client decision, not hard-wired into the protocol.
Cheers,
Geoff
Received on Thursday, 27 January 2000 23:56:07 UTC