Subject: Re: LOCK Scenarios

From: [email-masked]
Date: Wed, 18 Aug 1999 09:29:24 -0400

<JC>
A couple misunderstandings here.

1) I think Judith suggested that you were suggesting that
depth and singleton locks at the destination be treated
differently. At least that was my initial reading.  I've
not found evidence of you saying this though.  As it turns
out it looks like she missed the point of the distinction
between your expectations and Kevin's.  I think the
point is not singleton vs. depth... or singleton vs
inherited.  The point is whether
a LOCK that is rooted (singleton or not) at the destination
URI survives.
<jra>
depth only applies to the parent of the destination resource when determining if
the new destination gets the lock or not. I do not even consider the resource
type or what kind of lock it has with respect to the COPY or MOVE operation
because it doesn't matter, this lock is not retained. However, if the new parent
collection is depth infinity locked, the destination will inherit the lock
(regardless of what lock the deleted resource might have had), and if the
destination is also a collection, it will have a depth infinity lock too. Just
like it would if you had created the collection with MKCOL or a resource with
PUT.
</jra>
  BTW, I propose we use the phrases, "rooted at the URI"
vs "inherited at the URI/resource" when talking about
these locks.  As far as vocabulary goes, there are also
a few other cases that need vocabulary.  I'll save that
for a seperate note.
<jra>
I don't know what either of these phrases mean. A resource is locked or
unlocked. A resource inherites any depth infinity lock of its parent collection,
no matter how it became a member of that collection.
</jra>

2) It sounds like you also think that having support for
retaining a lock rooted on URI below a deleted URI is too
messy  to support.  If so, we agree.
That's why I made the proposal
above.  It eliminates everything that I'd consider a
"special case".  It does still leave the issue of if
the destination URI remains locked.  And lets the client
decide that.  I
think this is more of a feature than a special case to
handle.  The client simply declares if he wants to retain
the lock or not when he issues the DELETE.  Depending on
the implementation, the server might even find it *easier*
to support the keeping of the lock.  (AKA no code at all.)
But the proposal would be for the server to support both
behaviors at the DELETE request URI.
<jra>
I don't think the destination URL retains the lock of the resource that used to
be at that destination unless it just happens to have the same depth infinity
locked parent collection. But this would be a new lock with the timeout reset.
</jra>

3) 8.10.5 says a DELETE destroys a lock at the destination.
I think this is not optimal.  A scenario is...  /a/b  exists
and is a resource... not a collection.  We want to replace it
with a new resource that is a collection.  But the spec says
that MKCOL can not replace am existing resource (or
collection).  It requires that a delete be performed first.
Now if one wants to accomplish this atomically (with
LOCKS), right now one has several choices.
      a) LOCK /a/.  It would probably be a depth 0 lock since
  there would be no point in locking at depth except possibly
  to prevent someone from tossing in another lock immediately
  after in the /a/b/... tree.    But if they did chose to use
  a depth lock, they'd also risk being unable to get the lock
  if someone for example has a conflicting lock somehwere in
  a /a/c/ tree.  It's a trade off. Depth or not, the other
  disadvantage of it is that they are also locking out any
  operations on /a/.  The point is that if they decide to lock
  /a/, they are locking more than they need to and may
  interfere with other principles... or be blocked themselves.
      b) LOCK /a/b.  But unfortunately with the current spec,
  the initial DELETE will destroy the lock.  So this isn't
  really a choice unless we want to reissue the lock... to
  create a null lock which is better, but still risks problems
  if another entity beats us to the punch.  It's a race condition.

Now if we altered 8.10.5 to allow support for not deleting the
lock, we could act surgically to insure that we get exactly the
safe atomic behavior we want.  (Ignoring a tangential caveat.)
We lock /a/b possibly at depth.  Do the delete specifying that
we want the lock retained.  Then do the MKCOL /a/b/ and any
other operations we require.  When done, release the lock. Once
again ignoring an unspecified caveat, we know that as soon as
we get the lock that we're going to be able to acomplish what
we set out to do without another principle interfering.

If we don't want this, then I think we need to evaluate why we
support lock-null resources.  I'd think the arguments for each
of these are the same.
<jra>
There are a large number of situations in authoring environments where
transaction semantics are required. WebDAV doesn't (yet) support transactions,
and I don't think we should attempt to come up with a lot of special cases (like
lock-null resources) supported by the protocol to overcome this important
missing function. Rather let's propose an extension that does support
transactions. Might be pretty hard with a stateless server though.
</jra>

BTW, my final comment above has prompted me to check into the
history of destination lock deletion and lock-null resources...

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0245.html

Here Yaron's solution to atomicity in COPY.  It's not to support locks
on the destination.  It's to simply change the spec to say COPY should
be implemented atomically.  No explanation.  Just his recomendation.
Sounds reasonable.

http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/0041.html

There was a time where deleting a resource didn't necessarily delete its lock.
   Nov 96.

http://lists.w3.org/Archives/Public/w3c-dist-auth/1997AprJun/0135.html

But deleting the destination lock was in there April 97.  I could find
no explanation for the change.  It looks like they/Yaron decided to start
from scratch and this was the result. -- I believe this is also where
lock-null resources came in.  No earlier references to this.  No documentated
rationale behind it.  Yaron?

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 18 Aug 1999 16:26:35 -0400

<JC>  ...  The point is whether
   a LOCK that is rooted (singleton or not) at the destination
   URI survives. </JC>

<gmc>
I see at least two reasons in favor of deleting the lock:

- A MOVE/COPY just does a regular delete (with deletion of all locks),
rather than a "special delete" which deletes all locks except for the
one rooted at the destination URI.

- The MOVE/COPY protocol doesn't have to deal with the complexity of
applying the old lock to the new resource.  I can easily imagine the
creation of certain types of locks that only apply to certain types of
resources.  The MOVE/COPY protocol would then have to deal with all
the error conditions that LOCK has to deal with.

One clearly can extend the protocol to answer these questions, but it
makes for a significantly more complicated protocol.
</gmc>

   <JC> ...  The client simply declares if he wants to retain
   the lock or not when he issues the DELETE.  Depending on
   the implementation, the server might even find it *easier*
   to support the keeping of the lock.  (AKA no code at all.)

<gmc/> A server has to delete all of the LOCK's rooted at descendents
of the destination URI, so I don't see how it could be easier for it
to delete all descendent locks, but not the lock at the URI.

   <JC>  8.10.5 says a DELETE destroys a lock at the destination.
   I think this is not optimal.  A scenario is...  /a/b  exists
   and is a resource... not a collection.  We want to replace it
   with a new resource that is a collection.  But the spec says
   that MKCOL can not replace am existing resource (or
   collection).  It requires that a delete be performed first.
   Now if one wants to accomplish this atomically (with
   LOCKS), right now one has several choices. ...

<gmc/> I think this is better handled by just saying (as suggested by
Yaron) that a COPY/MOVE should be performed atomically, and not bother
with trying to use locking to achieve atomicity of COPY/MOVE.

Cheers,
Geoff

---

From: "Kevin Wiggen" <[email-masked]>
Date: Wed, 18 Aug 1999 15:55:48 -0700

OK not to make this any harder than it is....  But I have an issue on the
Webdav Issues list that a move/copy should not do the DELETE by itself,
ever.  This gives the client complete control and forces them to do the
delete before placing the file there.  This way my server is not making any
judgments about the existing resource for the user.

On a side note this has already been a complaint multiple times on
Sharemation, and it has only been up for 2 days.  People think that a
move/copy should be merging files, not overriding them.  Especially since IE
is telling them its doing a merge!!!  And I quote "This folder already
contains a folder named 'pictures'.  If the files in the existing folder
have the same name as files in the folder you are moving, they will be
replaced.  Do you still want to move the folder?"

Now I am not saying we should do something because Microsoft does it, but
this is the behavior I would be expecting....

If you follow this train of thought, if I replace 1 file with another, I
would expect things like creation date to be left alone.  I would expect
that only the bytes would change.  From this I would expect that any lock I
had would still be there....

Maybe I am complicating things too much, but I just felt I should mention
it...

Kevin