Subject: RE: Locking, moving and deleting

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 28 Sep 2001 14:29:05 -0400

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 a MOVE of a collection will delete all locks on URL's for that
collection,
but that doesn't necessarily remove all locks on the resources in that
collection.
For example, suppose the URL /x/foo.html and /y/bar.html are mapped to the
same resource.  If you LOCK /x/foo.html, and then MOVE /x/foo.html to
/z/foo.html,
the resource mapped to /z/foo.html is no longer locked.  If on the other
hand,
you LOCK /z/bar.html and then do the same MOVE, the resource mapped to
/z/foo.html
remains locked.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Friday, September 28, 2001 2:13 PM
To: Webdav WG
Subject: Locking, moving and deleting

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: "Lisa Dusseault" <[email-masked]>
Date: Sat, 29 Sep 2001 15:08:48 -0700

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 don't follow your example as well (reproduced below) because WebDAV
doesn't specifically allow for one resource to be mapped by several URLs.
Let's keep it simple and assume that a WebDAV system only maps URLs to
resources 1:1.

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.

Lisa

---