Subject: WebDAV Bindings - Issue Yaron.AtomicMove

From: Yaron Goland <[email-masked]>
Date: Sun, 16 Jan 2000 17:43:14 -0800

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.

An additional issue, beyond Yaron.AtomicDelete, is that MOVE in most file
systems is actually implemented as a copy followed by a delete, at least in
the case of directories. Hence file systems can not implement atomic moves.
Hence requiring atomic moves means that file systems can not implement
WebDAV.

Furthermore even though some of the more advanced file systems can handle
atomic MOVEs, they can only do so within a single volume. This would mean
that a server which had more than one file volume would have to refuse user
requests to move files across the volumes solely because it could not do so
atomically.

Finally, the title of DAV begins with a D for a very specific reason.
Requiring atomic behavior on MOVEs will prevent all but the highest end
systems from being able to MOVE files between systems because the
cooperating systems would have to implement a transactioning system between
themselves.

As such I move that the atomic MOVE language be struck from the BIND spec on
the grounds that it reduces interoperability, requires behavior that would
preclude file system based systems from supporting WebDAV and significantly
hinders WebDAV's ability to act in a distributed manner.

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 27 Jan 2000 23:56:05 -0500

From: Yaron Goland <[email-masked]>

   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

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