W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: WebDAV Bindings - Issue Yaron.AtomicMove

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 27 Jan 2000 23:56:05 -0500
Message-Id: <10001280456.AA29872@tantalum>
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.


   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.

Received on Thursday, 27 January 2000 23:56:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC