W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: Locking, moving and deleting

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 28 Sep 2001 14:29:05 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AC1E@SUS-MA1IT01>
To: Webdav WG <w3c-dist-auth@w3c.org>
The best way to explain the defined MOVE semantics for a LOCK is to say that
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
but that doesn't necessarily remove all locks on the resources in that
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
the resource mapped to /z/foo.html is no longer locked.  If on the other
you LOCK /z/bar.html and then do the same MOVE, the resource mapped to
remains locked.


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
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?

Received on Friday, 28 September 2001 14:29:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC