RE: Losing Locks on MOVE requests (Was: FW: [Moderator Action] Qu estions on Webdav Servers)

Ick we did choose 4 didn't we? I think someone eventually came up with the
compromise that you could move a locked resource but only if lost the lock.

As for #1, a certain unbelievably large vendor, who shall remain nameless,
became agitated at the possibility that the overwhelming majority of
humanity would loose the ability, with their current systems, to move a file
if it was locked.

BTW, if this rule is such an annoyance why not just add a mandatory
extension to require that the method fail if the lock can't be moved? The
WebDAV spec only effects the default behavior. If you add the "movelocks"
header to a request then the server is free to move the lock. You can then
use mandatory in cases where you absolutely insist that the movelocks header
be honored. So long as the server and client agree on a particular behavior
they can do anything they damn well please.

			Yaron

> -----Original Message-----
> From: Geoffrey Clemm [mailto:geoffrey.clemm@Rational.Com]
> Sent: Tue, August 10, 1999 10:36 AM
> To: Yaron Goland (Exchange); w3c-dist-auth@w3.org
> Subject: Losing Locks on MOVE requests (Was: FW: [Moderator Action]
> Questions on Webdav Servers)
> 
> 
> The message in WBW gives 4 choices:
> - fail the move if locks cannot be retained
> - try to maintain the locks, but let the move succeed even if 
> the cannot be
> retained
> - require that locks be retained on a move
> - disallow a move on a locked file
> 
> You then voted for the last choice.  I'm not sure how this 
> then resulted in
> the
> current semantics of "allow the move but strip off the 
> locks".  Are there
> other
> messages that provide the intermediate reasoning?  In particular, I'm
> looking
> for a counter argument to:
> 
> #1 seems to be a preferable choice, since it is trivial for
> both lock-preserving and lock-losing servers to implement, 
> and a client
> needs to
> deal with a variety of failure cases for a move anyway.  
> Having "cannot move
> locked file" be one of them does not seem much of an 
> additional burden, and
> it does not force servers that can move locked objects to gratuitously
> remove
> all locks, and then have the client add them all back again.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Yaron Goland (Exchange) <yarong@Exchange.Microsoft.com>
> To: 'Geoffrey M. Clemm' <gclemm@tantalum.atria.com>; ejw@ics.uci.edu
> <ejw@ics.uci.edu>
> Cc: w3c-dist-auth@w3.org <w3c-dist-auth@w3.org>
> Date: Friday, August 06, 1999 1:15 PM
> Subject: RE: FW: [Moderator Action] Questions on Webdav Servers
> 
> 
> >Section 7 of the WBOW vAlpha2
> >(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar
> /0129.html)
> >point to
> >http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/
> 0177.html
> which
> >explains the reasoning.
> >
> > Yaron
> >
> >> -----Original Message-----
> >> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> >> Sent: Sat, July 24, 1999 8:39 PM
> >> To: ejw@ics.uci.edu
> >> Cc: w3c-dist-auth@w3.org
> >> Subject: Re: FW: [Moderator Action] Questions on Webdav Servers
> >>
> >>
> >>
> >>    From: Kevin Wiggen [mailto:wiggs@xythos.com]
> >>
> >>    The following are a few more questions I have.
> >>
> >>    ...
> >>
> >>    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.
> >>
> >> I believe that the complexity here is due to the decision to have a
> >> WebDAV lock be *both* a resource state lock (which means 
> the state of
> >> the resource is locked no matter what URL you use to access it)
> >> *and* a URL lock (which means that you have a lock on 
> whatever might
> >> appear at that URL).
> >>
> >> This was done for some very good reasons, since you need both kinds
> >> of locks to ensure that "when you have the lock, only you 
> can change
> >> what is at that URL".
> >>
> >> Unfortunately, the expected behavior of those two kinds of locks is
> >> different under MOVE and DELETE, and the current WebDAV 
> semantics ends
> >> up with (is forced into) a compromise semantics that produces
> >> counterintuitive behavior from either perspective.
> >>
> >> In particular, one would expect a URL lock to be 
> unaffected by a MOVE
> >> or a DELETE.  If you've got a URL locked, you should be 
> able to move
> >> anything to it or from it (or even delete it, resulting in a locked
> >> null resource).  This I think is the perspective Kevin was taking.
> >>
> >> But a resource state lock acts very differently.  If you delete a
> >> resource, the resource state lock should be deleted as 
> well (no state
> >> left to lock).  This is what WebDAV says.  But if you MOVE 
> a resource,
> >> you'd expect the resource state lock to remain in effect.  But here
> >> WebDAV goes with the URL lock semantics and says that a 
> MOVE deletes
> >> the lock.
> >>
> >> Personally, I can live with most of this except for the 
> losing of the
> >> lock on the move.  Can someone point me at something in 
> the archives
> >> that explains this decision?  I didn't find it in Yaron's WBOW.
> >>
> >>    4)  I assume that a null resource can be created via a URL
> >> with a trailing
> >>    slash and one without.  If I create one with a trailing
> >> slash, can I only do
> >>    a MKCOL later?  If no trailing slash is sent, the server
> >> probably needs to
> >>    assume that the client might have just not sent the slash
> >> and allow a MKCOL
> >>    or a PUT.  I think the spec should state that a NULL
> >> RESOURCE can be created
> >>    with a trailing slash or not, AND any NULL RESOURCE can
> >> take a MKCOL or PUT.
> >>    (You already messed up some of the beauty of my server
> >> with Null Resources,
> >>    I would hate to put even more if statements in to handle
> >> the above....)
> >>
> >> I agree with Kevin.
> >>
> >> Note: These kinds of questions would not arise if
> >> WebDAV would just state that /foo/x/ and /foo/x always map to
> >> the same resource (JimW and I periodically go round on this
> >> one :-).  Even Windows and Unix agree that this is
> >> the sensible approach.
> >>
> >> Cheers,
> >> Geoff
> >>
> >
> >
>

Received on Tuesday, 10 August 1999 13:57:51 UTC