RE: Questions on Webdav Servers, MOVE and dest LOCK

Why don't we do this:

When you lock a collection:
  depth 0:  
    shared lock placed on the collection resource: 
           no one can add or delete members
    exclusive lock placed on the collection resource: 
           only you can add or delete members.
  depth 1:
    shared lock on coll.: no one can add or delete members.
                 First level members that exist at that time have
                 a shared lock placed on them.
    exclusive lock on coll.: only you can add or delete members.
                 First level members that exist at that time have
                 an exclusive lock placed on them.
  depth infinity:
    shared lock on coll.: no one can add or delete members.
                 Members at any level(including subcollections)
                 that exist at that time have
                 a shared lock placed on them.
    exclusive lock on coll.: only you can add or delete members.
                 Members at any level (including subcollections)
                 that exist at that time have
                 a shared lock placed on them.
When a resource is moved out of or into a collection, the lock(s)
of the resource don't change (assume the move is allowed).
No locks are ever created or deleted as a result of an ordinary
resource or collection resource being moved (assume the move is
allowed).

When you unlock a collection, depth n, you do the inverse
of the operation described above on the members that exist
at the time the unlock of the collection is executed.

Remember that a resource can be in multiple collections at
the same time. In fact, in some systems, that is the normal
case. If a resource X is in two collections C1 and C2,
locking C1 does not prevent the resource X from being removed
from collection C2. Nor does it prevent the resource X from
being inserted into collection C3. There are no locks
placed or removed as side effects of MOVE. Only LOCK,
UNLOCK, and DELETE mess with locks.

Alan Babich

-----Original Message-----
From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
Sent: Tuesday, August 03, 1999 1:17 PM
To: w3c-dist-auth@w3.org
Subject: RE: Questions on Webdav Servers, MOVE and dest LOCK


[caught in spam filter -Ralph]

From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>, w3c-dist-auth@w3.org
Date: Tue, 3 Aug 1999 14:23:36 -0400

I think it was our intention that the advanced collection spec be consistent
with the lock semantics described in rfc 2518.  In fact, we explicitly say
this is the case in 4.2.11 LOCK and UNLOCK.

However, it's also true that we didn't consider interactions with locks when
we were defining MOVE semantics.  If you just read 4.2.10 MOVE and Bindings,
you would probably expect that if a resource was locked before a MOVE, it
would still be locked after the MOVE; and if it was not locked before a
MOVE, it would not be locked after the MOVE.

So I think we say or imply conflicting things in the advanced collections
spec, and we need to figure out what we really want our story to be.  I
agree that we need to address these cases explicitly.

My own feeling is that when you MOVE a resource, the result is the same
resource, with all the same properties, at a different location.  So it
should have the same lock that it had at the source location.  

On the other hand, when we are thinking about simple resources inheriting
locks from their parent collections, and moving a bunch of these resources
around, it is certainly simpler to manage the locks if the simple resources
inherit locks dynamically from their parent collections -- so that when you
unlock a collection, you unlock all the resources that are in it at the time
of the unlock rather than the ones that were in it when the lock was applied
(which may reside anywhere by the time the lock is removed).

The earlier rationale for having MOVE destroy the lock on a resource is at
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html.


> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Monday, July 26, 1999 9:48 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: [Moderator Action] Questions on Webdav Servers, MOVE and
> dest LOCK
> 
> 
> 
> <prev>
> > 3)  MOVE/COPY to a destination that is locked.  8.10.5 states "... a
> > successful DELETE of a resource MUST cause all of its locks to be
> > removed."
> > and 8.8.4 states that overwrite set to T will do a DELETE....
> > Then will the
> > LOCK on the destination be lost??  This seems wrong to me.  If the
> > destination is LOCKED, then after a MOVE/COPY which might delete the
> > resource, I would assume the resource is still locked.
> 
> If the destination of a COPY/MOVE is locked, and you submit 
> the lock token
> of the destination lock in the If header, then the intent of 
> RFC 2518 is
> that the destination resource should be locked.  This is stated in the
> second paragraph of section 7.7.
> </prev>
> 
> Note: Although I don't think we deal directly on the topic of
> locks at the destination in the Adv Coll spec, 7.7 does seem to
> be in disagreement
> with the MOVE semantics of the Adv. Coll. proposal. If anyone
> feels strongly that section 7.7 should remain
> as is, I suggest that they do a read of the Adv Coll
> document and then express their opposition.  I just don't
> want our Adv Coll work in this area to surprise anyone.
> 
> We also should make sure that the Adv Coll document is *clear*
> on what should happen in this situation.  My opinion is that
> the destination lock should go away as should the locks of
> any decendent nodes in the URI tree at the destination.  I
> could be persuaded otherwise for a lock on the destination
> URI/resource specifically though.
> 
> J.
> 
>

Received on Thursday, 5 August 1999 18:38:30 UTC