Subject: Re: Move and Delete (was: bind draft issues)

From: Jason Crawford <[email-masked]>
Date: Mon, 3 Mar 2003 15:37:41 -0500

On Monday, 03/03/2003 at 11:28 PST, Brian Korver
<[email-masked]> wrote:
> On Saturday, March 1, 2003, at 06:27  AM, Clemm, Geoff wrote:
> >
> >    From: Brian Korver [mailto:[email-masked]]
> >
> >    Move and Delete
> >
> >    The spec states that move and delete are merely operations
> >    on bindings.  At the very least, this is inconsistent with
> >    2518,
> >
> > How is this inconsistent with 2518 (other than the use of
> > terminology not defined in 2518)?
>
> 2518 correctly states that MOVE (and COPY) also may involve
> a DELETE with "Depth: infinity" operation in the case of
> overwrite.
It supports that.  What you're possibly refering to is the fact that
2518 let's the DELETE on a collection to delete some of the
children and abort before removing the colection itself and without
backing out what it did.   In the Bind Spec, there is no requirement
to unbind those child resources and in many cases you definitely
don't want to do that.   You only have to unbind the collection.
There is no partial DELETE.  You just have to unmap that collection.
Whether that reclaims resources is a different matter.

> DELETE also operates on more than bindings.  Consider,
> for instance, what happens to locks.
Yes, you can't break a lock without having the proper lock
token submitted, but you're not allowed to break the lock, but
abort the DELETE.  Nor are you somehow allowed to unmap
the resource but not remove the lock.  (At least not yet. :-))

> My reading of the document is different, so the language
> should be cleaned up so that it doesn't sound like it is
> prohibiting the semantics spelled out in 2518.  Would it
> help if I provided that text?
I actually just read it for the first time in a long time and it's very
clear
that it doesn't speak of freeing up resources.   Except to say that you
"MAY" do it.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 3 Mar 2003 19:48:59 -0800

> Whether that reclaims resources is a different matter.

Would you be able to do that -- unmap a collection -- even if one of its
children were locked? The person with the lock would then lose it and
their resource, right?

If on the other hand, you can't unmap a collection until all its
children are unlocked, then you have a serious problem supporting that
atomically on a filesystem. For example, by the time IIS 5.0 checks all
the children of a collection to see if they're locked, one of them might
have just gotten a new lock.  

Lisa