Subject: Locking, moving and deleting

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 28 Sep 2001 11:13:24 -0700

In general, I think WebDAV ties locks to resources.  I think this is
embodied in a few things we take for granted:

 - DELETE a resource, and its lock goes away.
 - LOCK a URI that doesn't have a resource, and DAV requires you to create
one (a LNR).

However, there's a statement in the spec that flies in the face of that: "A
successful MOVE request on a write locked resource MUST NOT move the write
lock with the resource. "

You could justify that exception by saying yes, in general, locks are tied
to resources but do not survive moves.  But does that work??  What if you
MOVE (or rename!) a collection that has locked or lock-null resources inside
it?  If you follow the logic that locks do not survive moves, then you must:
 - remove all the locks of all the children, including LNRs
 - remove the LNRs, now that their locks are gone

Does any server follow that behaviour?  Or are locks in practice preserved
on some or all MOVE operations?

lisa

---

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 30 Sep 2001 01:24:27 -0400

From: Lisa Dusseault [mailto:[email-masked]]

   On Behalf Of Clemm, Geoff
   > The best way to explain the defined MOVE semantics for a LOCK
   > is to say that a LOCK is on a URL, but that it is deleted
   > when the resource mapped to that URL is deleted.

   So far I can follow; it's not a bad model.  I'd append "or moved"
   to the end; most people will consider this different than "deleted"
   because we have different methods for MOVE and DELETE.

I agree that is worth making explicit to avoid any confusion.

   I don't follow your example as well (reproduced below) because WebDAV
   doesn't specifically allow for one resource to be mapped by several URLs.

WebDAV allows for one resource to be mapped to multiple
URL's because HTTP specifically allows for one resource to be mapped
to multiple URL's.  In particular, section 9.6 of RFC 2616:

 "A single resource MAY be identified by many different URIs. For
 example, an article might have a URI for identifying "the current
 version" which is separate from the URI identifying each particular
 version."

Therefore the locking protocol (and the rest of WebDAV) must have
well defined behavior in those cases where multiple URL's do identify
the same resource.

   Let's keep it simple and assume that a WebDAV system only maps URLs to
   resources 1:1.

That's fine, but it is good to keep the multiple mapping scenario in
mind for when someone suggests a "simpler" model that does
not handle the multiple mapping scenario.

   That means that when a collection containing null resources is
   moved or is renamed, all the locks in the collection disappear, and
   the null resources must be cleaned up.  That seems contrary to what
   the users would like to see happen; that's the scenario that made
   me rethink the way this works.

The loss of the locks is inherent in a "lock is on the URL" model.
The reason the "lock is on the URL" model is superior to the
"lock is on the resource" model can be seen by looking at the two
cases for moving a locked resource.

- If the client holding the lock does the move, it can easily lock
the destination collection with a new depth lock, and then perform the
move (the resources will be captured by the new depth lock).

- If some other client not holding that lock does the move (if it is a
shared lock, for example), there often is no good way for
for the client to "find" the resource after it has been moved (since
all the client has is a URL and a lock token).  While we were debating
this a while back, several vendors objected to the proposal that we
require a server to allow a client to easily find a locked resource by using
the lock token (PROPFIND Depth:Infinity on "/" is not considered a
good way :-).

Also, note that the current proposal for LOCK'ing an unmapped resource
(i.e. creating a real resource there) would leave those empty resources in
place to be captured by the depth lock at the destination.

Cheers,
Geoff