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:12:06 UTC