RE: [Moderator Action] Questions on Webdav Servers, MOVE and dest LOCK

See comments in <jra> tags below on locks with COPY/MOVE




ccjason@us.ibm.com on 07/26/99 09:47:36 PM

To:   w3c-dist-auth@w3.org
cc:

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>
<jra>
I think this is an incorrect interpretation of section 7.7. The original lock on
the destination of COPY/MOVE is always lost. Section 7.7 says what happens when
the destination is within the scope of a depth lock, that is, the resource at
the new location is a member of a collection locked with depth infinity. In this
case, the lock is not retained, the destination resource gets a new lock.

The purpose of the lock token in the If header for the COPY/MOVE destination is
to allow the overwrite if necessary. It has no effect on the lock status of the
destination resource after the COPY/MOVE method.
</jra>

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 Monday, 16 August 1999 10:40:34 UTC