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

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 5 Mar 2003 08:58:33 -0500

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.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]

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

Brian,

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

Julian

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 8 Mar 2003 07:56:54 -0800

> information lossage inherent in copy/delete.
That seems unrealistic to me.  Clients have shown that they don't care
about propertybehavior -- none of them implemented that part of RFC2518.
They just want to do a move! 

A server can often do a better job of move than the client's copy/delete
attempt.  Even if the server must transfer resources from one partition
to another, the server can at least set properties like "creationdate"
to the creation date.  A user doing a COPY will cause "creationdate" to
be initialized to the time of the COPY, and many servers don't allow
that property to be written. 

Neither the client nor the server can guarantee a 100% perfect
cross-partition move operation, but because the server can short-circuit
some permissions issues, the server is much more likely to do a much
better job.  

lisa