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

From: Jason Crawford <[email-masked]>
Date: Mon, 3 Mar 2003 23:42:08 -0500

On Monday, 03/03/2003 at 07:48 PST, "Lisa Dusseault"
<[email-masked]> wrote:
> > > 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.
>
> 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?

What you are implying is correct.
If a child is locked via a WebDAV lock and the binding to be DELETEd is
protected by the protected URL of that lock, then it can't be unmapped.
If the inode of the child is locked, then I believe it can be unmapped.
If it's locked by a Win32 lock then it probably can't be unmapped in
the file system, so it's probably best to reject the DELETE at the
WebDAV layer.

> 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.

If we're talking about webdav's locks, it should be handleable inside the
server and it should be manageable.  If we're talking about
 a file system lock, then it might depend on the OS.  I
believe on Linux for example that it doesn't matter if an inode is locked.
The resource can move/delete and the resource remains locked and file
handles
are not broken.  In the
case of Win32, you probably can go through the same process as the
Win32 CMD.EXE MOVE command does.  It does take a few seconds
looking for locks in descendents in large trees... but I assume it also
deals with locks
being created while it's looking.  If that MOVE succeeds, then that binding
should be WebDAV DELETE'able.  If that MOVE is rejected, then you
probably will need to reject the WebDAV bind-enabled DELETE.

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 4 Mar 2003 11:51:31 -0800

> the file system, so it's probably best to reject the DELETE at the

I don't think the bindings specification makes clear what you've just
said here. It's probably because you've internalized a data model that's
been discussed on the list, and are making conclusions based on the
model.  This kind of information should be added to the specification,
because even when models are written down, they can easily be
interpreted differently by newcomers. 

Lisa

---

From: Brian Korver <[email-masked]>
Date: Tue, 4 Mar 2003 15:54:12 -0800

On Monday, March 3, 2003, at 08:42  PM, Jason Crawford wrote:
[snip]
> believe on Linux for example that it doesn't matter if an inode is 
[snip]

Just FYI, in linux, it depends on the type of lock.  See 'i' in 
chattr(1)
for more info.

-brian
[email-masked]