- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sat, 29 Sep 2001 15:08:48 -0700
- To: "Clemm, Geoff" <gclemm@rational.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
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 --- Geoff's example: > > 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: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? > > lisa
Received on Saturday, 29 September 2001 18:10:03 UTC