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

An important thing to keep in mind is that we do not
expect all repositories to be capable of supporting the BIND
method (in particular, the creation of multiple bindings to
a collection).  But we do require that a repository that
supports the BIND method also supports atomic DELETE/MOVE.

Just for interests sake, how many examples are there of
repositories that do support multiple bindings to a collection
but cannot support atomic DELETE/MOVE?

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

On Monday, 03/03/2003 at 07:48 PST, "Lisa Dusseault"
<nnlisa___at___xythos.com@smallcue.com> 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,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

Received on Tuesday, 4 March 2003 10:11:42 UTC