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

ailto:nn683849@smallcue.com]
> Sent: Wednesday, March 05, 2003 1:36 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
>
>
>
> > > Right.  To claim BIND spec support, you have enhance the
> implementation
> to
> > > support *this*  2518 compliant approach.... or to avoid a situations
> where
> > > bind spec
> > > violations would happen.   It's not unreasonable to expect one to have
> to
> > > add code
> > > in order to support a new feature like multiple-bindings.
> >
> > Actually, I'd have to remove code.
> >
> > The issue isn't that the server can't *technically* do this -- it's that
> the
> > this semantics isn't compatible with the existing DELETE
> semantics of our
> > system. Just removing the collection binding without checking that all
> > internal members may be deleted as well simply is *not* an option.
>
> Okay, so I'll stop talking about symbolic links :-)
>
> If there are multiple bindings to a collection and a WebDAV request asks
> you do DELETE one of them, will your server end up deleting all the
> descenent bindings also... or just the one requested?

If it's one of many bindings: just the binding. If it's the last binding, it
will do a best effort DELETE as allowed in RFC2518.

> Is it not possible to freeze the system while your system checks this?
> Perhaps in a way similar to the way the Win32 has to before it allows
> a MOVE.  In its case, is seems to find it acceptable to delay while
> it's checking this.  It can cause a delay of a few seconds, but apparently
> the folks that implemented that found it acceptable.

A MOVE is a simple namespace operation. All it needs to do is check locks.

A DELETE that cleans up in the foreground will need to check delete
privileges on all descendants. This set can be very huge. I think it's an
extremely bad idea to do this in a single transaction (yes, we tried).

> > So basically we have the choice between
> >
> > - supporting multiple bindings, but not the BIND method described in the
> > draft, or
> > - simply ignore this requirement.
>
> Or I suppose, "not allow multiple bindings to collections?"

Even then I can't complain conformance to the spec. It doesn't allow me to
have a best effort DELETE on collections at all.

> > I'd rather have a spec that I can implement without having to break a
> > specific requirement (in particular if i'm not convinced it adds value
to
> my use case).
>
> The other day I ran in to this in a non-WebDAV situation.  I tried to move
> a huge
> directory.  I found it frustrating to find that it was moving the
> files one
> at a time and
> ran in to a problem and left me with two partial trees.  (This was across
> file systems.)
> I would have been similarly, although less problematically, frustrated if
> it had been
> a delete request.

I notice you keep mention MOVE. We don't disagree here. MOVE must be atomic.
If you can't MOVE, let if fail. If it fails the client still can do a COPY
and the DELETE the source.

DELETE is really a separate topic!

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 4 March 2003 19:48:18 UTC