RE: Bindings, Locks, and MOVE

As I noted in the message that started this thread, our proposal contradicts
what RFC 2518 says about preserving locks on a MOVE.  We would like to see
the WebDAV spec changed when it goes to draft status to say that locks are
*not* lost on a MOVE.

Judith A. Slein
XR&T/Xerox Architecture Center
jslein@crt.xerox.com
8*222-5169


> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> Sent: Wednesday, September 08, 1999 11:12 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: Bindings, Locks, and MOVE
> 
> 
> 
> 
> The WebDAV spec says that locks are lost on MOVE. So if the 
> source resource is
> locked, then the MOVE request must include the lock token, 
> and the lock must be
> owned by the requesting principal. Otherwise the delete 
> portion of the move will
> fail. Since MOVE is a best effort method, the copy to the 
> destination will work,
> even if the source can't be deleted. As is the case with 
> COPY, the lock on the
> destination resource is determined by its new parent 
> collection, not by any lock
> state it may have had. This could be taken to mean that the 
> new resource is not
> the same resource moved to a new location, but a different resource.
> 
> 
> 
> 
> 
> "Slein, Judith A" <JSlein@crt.xerox.com> on 09/08/99 09:34:03 AM
> 
> To:   "'Yaron Goland (Exchange)'" <yarong@Exchange.Microsoft.com>,
>       w3c-dist-auth@w3.org
> cc:
> 
> Subject:  RE: Bindings, Locks, and MOVE
> 
> 
> 
> 
> The intention is that if a resource is copied or moved into a 
> tree that is
> locked, the lock on the tree remains in force.
> 
> We didn't discuss the case where you are doing a MOVE, and 
> the resource
> being moved is locked, and it is being moved into a collection that is
> locked.  The lock on the collection will certainly stay in 
> force, but we
> need to decide whether the lock on the resource being MOVEd 
> will be lost or
> whether the MOVE will fail.  I guess my own opinion is that 
> the MOVE should
> fail, since that maintains a consistent position that the 
> state of a MOVEd
> resource should be unaffected by the move; if its lock state 
> would have to
> be changed, the move should fail.
> 
> Judith A. Slein
> XR&T/Xerox Architecture Center
> jslein@crt.xerox.com
> 8*222-5169
> 
> 
> > -----Original Message-----
> > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com]
> > Sent: Tuesday, September 07, 1999 8:49 PM
> > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org
> > Subject: RE: Bindings, Locks, and MOVE
> >
> >
> > Phew!!! I couldn't believe what I was reading regarding write
> > locks. What
> > use is a write lock that only sometimes is a write lock?
> > Yikes. I'm glad
> > that is dead.
> >
> > However there is still a point in the original post that
> > concerns me. Let's
> > see if I understand the proposal:
> >
> > When copying a resource into a tree that is currently locked
> > then the lock
> > on that tree is lost?
> >
> > Is that the proposal for how to handle locks at the
> > destination of a copied
> > resource? That is my reading of the paragraph Judy provided.
> >
> >         Yaron
> >
> > > -----Original Message-----
> > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > > Sent: Tue, September 07, 1999 7:19 AM
> > > To: 'Greg Stein'; w3c-dist-auth@w3.org
> > > Subject: RE: Bindings, Locks, and MOVE
> > >
> > >
> > > Thanks for bringing the discussion back to earth.
> > >
> > > I agree with you that the compromise of saying that servers
> > > SHOULD protect
> > > the path of the Request-URI used in locking a resource is a
> > > poor one.  It
> > > doesn't respond to the issue that was raised, and it
> > > needlessly muddies the
> > > waters for clients, which now don't know whether the path
> > > will be protected
> > > or not.
> > >
> > > I like your suggestion that we keep the MUST language, but
> > > state that it
> > > applies only to write locks.
> > >
> > > --Judy
> > >
> > >
> > > > -----Original Message-----
> > > > From: Greg Stein [mailto:gstein@lyra.org]
> > > > Sent: Friday, September 03, 1999 3:24 AM
> > > > To: w3c-dist-auth@w3.org
> > > > Subject: Re: Bindings, Locks, and MOVE
> > > >
> > > >
> > > > This whole thread (post-Judy's message) seems to be picking
> > > out a very
> > > > minor detail of her post. Personally, I find this nit-picking
> > > > of detail
> > > > counter to the goal of her original post: "test its
> > > > conclusions with the
> > > > mailing list members."
> > > >
> > > > For myself (and mod_dav), the first "AGREED" portion
> > makes complete
> > > > sense, and I do agree with it.
> > > > [btw, is *anybody* going to be implementing cross-server
> > > MOVE/COPY? is
> > > > it necessary to have that feature in the spec at all? of the
> > > > umpteen DAV
> > > > servers out there now, I don't know any that do this or plan
> > > > to do this.
> > > > It would be nice to cut the thing and not worry about it.]
> > > >
> > > > The second "AGREED" portion does not make a whole lot of
> > sense. The
> > > > commentary states that the position is too strong [because it
> > > > might not
> > > > make sense with other types of locks]. Are there other locks
> > > > out there?
> > > > Do people have concrete, useful examples? I haven't heard
> > > of anything
> > > > besides a write-lock yet. Regardless, I think it should be
> > > enforced in
> > > > the spec that a write-lock MUST have guaranteed 
> protection of the
> > > > Request-URI. Put in some language that says other locks can
> > > define the
> > > > MUST/SHOULD nature of protection. Otherwise, leave it in
> > > the intuitive
> > > > state: a write lock says that others cannot monkey with 
> your URI.
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > Edgar Schwarz wrote:
> > > > >
> > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote:
> > > > >
> > > > > >    From: ccjason@us.ibm.com
> > > > > >
> > > > > >    <JS>
> > > > > >    This discussion began with Yaron's comment that saying
> > > > that "it MUST NOT be
> > > > > >    possible for a principal other than the lock owner to
> > > > make a locked resource
> > > > > >    inaccessible via the URI mapping used to lock the
> > > > resource" is too strong.
> > > > > >    It may make sense for write locks as defined in RFC
> > > > 2518, but may not make
> > > > > >    sense for other sorts of locks that don't restrict
> > > > MOVE and DELETE.
> > > > > >    </JS>
> > > > > >
> > > > > >    I believe that this is not specific to any particular
> > > > type of locks.  All
> > > > > >    clients need to insure that they have at the very
> > > > least a way to unlock
> > > > > >    the the locks they have created.  I assume that to
> > > > unlock (a resource), we
> > > > > >    have to provide a URI of a (the?) resource locked by
> > > > that lock... so if
> > > > > >    someone else changes the URI, it's
> > > > > >    very likely that we're not going to be able to figure
> > > > out what the new
> > > > > >    URI is... and will have to leave the lock around until
> > > > it times out.
> > > > > >
> > > > > > <gmc> Since the server needs to deal with this in case
> > > > the client just
> > > > > > neglects to remove the lock, and if having another client
> > > > MOVE your
> > > > > > locked resource is a rare occurrence (which I believe
> > > it is), then
> > > > > > this does not seem to be especially problematical.
> > > > > Would it be possible to say:
> > > > >   If a locked resource is moved the server SHOULD create
> > > a indirect
> > > > >   reference resource which should exist for some 
> sensible time.
> > > > >
> > > > > Yes I know, it's complicating the server :-)
> > > > > I imagine the above happening perhaps when somebody is
> > > reorganizing
> > > > > a directory structure and deep in the collections 
> there are some
> > > > > locked resources.
> > > > > So the lock owner at least has a decent chance to find
> > > out where his
> > > > > resource has gone to.
> > > > >
> > > > > Regards, Edgar
> > > > >
> > > > > --
> > > > > Edgar.Schwarz@de.bosch.com ON/EMS1, 07191/13-3382
> > > > Niklaus Wirth:
> > > > > Privat kann jeder soviel C programmieren oder Videos
> > > > ansehen wie er mag.
> > > > > Albert Einstein:  Mach es so einfach wie moeglich, aber
> > > > nicht einfacher.
> > > >
> > > > --
> > > > Greg Stein, http://www.lyra.org/
> > > >
> > >
> >
> 
> 
> 
> 
>

Received on Wednesday, 8 September 1999 11:47:01 UTC