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

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 5 Mar 2003 08:58:33 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE2021C59E2@SUS-MA1IT01>
To: "'WebDAV'" <w3c-dist-auth@w3.org>

I agree with Julian.  
The protocol that is used to implement something like "mv" should
be an operation that preserves all characteristics of the objects,
so the client (not the server) can decide whether to accept the
information lossage inherent in copy/delete.


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]

> From: Brian Korver
> On Tuesday, March 4, 2003, at 04:48  PM, Julian Reschke wrote:
> [snip]
> > 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).
> [snip]
> Julian,
> I agree, but I think it's even worse than this.  Semantically,
> MOVE is merely a simple namespace operation, but in practice
> it may be more than that.  For instance, a move across unix
> filesystems must be implemented as a recursive copy (followed
> afterward by delete).


in the Unix API, you don't move at all -- you link() then unlink(). "mv" is
just a user command that does it's best when the files reside in different
partitions. I think WebDAV MOVE should just fail if the resource cannot
really be moved (preserving all dead & live properties), and fail otherwise.
Just like in the Unix API, the caller *then* can decide to do a COPY/DELETE


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 5 March 2003 08:58:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC