W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 8 Mar 2003 08:40:51 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOECNGLAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Friday, March 07, 2003 10:37 PM
> To: 'Julian Reschke'; 'Jason Crawford'
> Cc: 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
>
>
> > 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).
> >
>
> Actually, collection MOVE suffers from the same problems as collection
> DELETE.  Here are some of them.
>  - You can't MOVE a file you don't have permission to write. Therefore,
> the server must check write privileges on all descendants.

I think I disagree. I *can* MOVE a resource without having write permissions
to the resource itself. What I need is the write permission on source and
targer collection (+ some more when overwriting something else).

>  - A WebDAV application server may be used to unify a number of back-end
> storage servers under the same namespace.  So the server's URL
> http://www.example.com/software/ may contain files stored on
> //davfiles/software, whereas the server's URL
> http://www.example.com/userdocs/ may contain files stored on
> //davfiles/userdocs.  A server moving a collection from one of these

Sure.

> top-level-directories to the other would have to do a network
> cross-repository move under the covers. This may not be feasible to do
> atomically.

Yes, that's why many people would prefer it to fail (leaving the client the
choice to explicitly COPY/DELETE) rather than doing something the client
din't really want.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 8 March 2003 02:41:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:03 GMT