Semantics of COPY and MOVE

A few days ago, I submitted the following questions:

<question>
Section 6.5 says "... a lock token MUST be submitted by an authorized principal
in the If header for all locked resources that a method may interact with or
the method MUST fail." Should this have been "... all locked resources that a
method may modify or the method MUST fail"? The example follows this rule as
the lock token destination is the only one required for the COPY method. If
this is the case, what about resource that are indirectly modified by a method?
Do their lock tokens have to be provided too? For example, consider a
collection that is not depth locked, but contains a resource that has an
exclusive lock. Deleting the collection causes the locked resource contained in
it to be modified. Does the DELETE method have to have an If header containing
the locked resource as well as the collection?
</question>
<question>
Section 6.6 says "A MOVE MUST NOT move the write lock with the resource...".
But it doesn't say what happens if this is attempted. Does the move fail on
this resource, or does the move occur and the lock is removed? I assume the
move fails on this resource but continues to move as many resources as
possible. So for example, if a user attempts to move a collection that is
unlocked, but contains a resource locked by another user, the collection is
moved, but not the locked resource. What if the resource is locked by the user
doing the move? Is the resource moved in this case? If so, is the lock
retained? It would be surprising if a user lost his locks when moving a
collection.
</question>

After re-reading the spec and giving this some more thought, I think the WebDAV
spec does describe consistent and complete semantics for COPY and MOVE with
respect to locking. In case anyone else experienced the same confusion I did,
here is an explaination that might help.

A COPY method is semantically equivalent to a GET followed by a PUT (or MKCOL
for collections), including recursively members of a collection if the source
is a collection. Locks on the source have no effect and need not be included in
the If precondition for COPY as GET is not effected by locks. Since PUT is
effected by locks, the application requesting a COPY must include lock tokens
for all locked resources in the destination of the COPY. If the destination is
a collection, the precondition must include the destination collection, if it
is locked, and recursively all of its locked children. Of course the requesting
principal must also own the locks, have sufficient access privileges to modify
the destination targets, and the COPY must have overwrite header equal to "T"
to copy over existing destination targets if any. Locks are not copied as the
copied resource is a different resource, and the lock token could not be the
same as that for the source resource. COPY is executed best effort meaning that
all resources that can be copied are copied, and in such a way that a
consistent collection namespace is maintained. Resources that cannot be copied
either because of locks not owned by the requesting principal, insufficient
access privileges, or missing overwrite header do not cause the COPY method to
fail for all resources. The COPY method returns either a 201 status code
indicating the COPY succeeded, or a multistatus indicating which resources
could not be copied.

A MOVE method is semantically equivalent to a COPY followed by a DELETE. In
this case, locks tokens for both the source and destination are required. The
locks for the destination are the same as for COPY while locks for the source
are required in order to delete the source after the copy. Move is also
executed best effort meaning that as many resources are copied to the
destination as possible, and as many, potentially different, resources are
deleted from the sources as possible, again subject to maintaining valid
namespaces. Move cannot move locks for the same reason COPY doesn't copy them.
After a move, the resources are different, they have a different URI
identifier, and the original locked resources have been deleted.

So the answer to the above question is that a MOVE request submitted by a pr
incipal who does not own the locks on some of the source and/or destination
resources both fails on resources that are not locked by the requesting
principal, and succeeds, removing the locks, on other resources. If a user
attempts to move a collection that is unlocked, but contains a resource locked
by another user, the collection is moved, including the locked resource, but
not locked source resource is not deleted. If the resource is locked by the
user doing the move, the resource is moved and the lock is deleted. Finally, it
is not possible to subvert locking by moving a resource causing the lock to be
deleted, modifying the resource, and then moving it back. This is because the
MOVE would partially succeed in that the resource would be copied, but the s
ource would not be deleted due to the lock. This would make it impossible to
move the edited resource back to its original location.

Received on Sunday, 12 July 1998 20:30:15 UTC