Re: question about MOVE and COPY overwriting folders

You should feel free to fail any operation that you feel is inappropriate
for your repository.  WRT the semantics of depth COPY, RFC-3253 modifies
the definition of COPY to indicate that it overwrites the existing 
resource,
rather than deleting it first (for the reasons that you identify), so you
should feel free to implement COPY that way.  On the other hand, MOVE
with overwrite does delete the destination, so you should fail that 
operation
if you don't like that behavior.

Cheers,
Geoff

John wrote on 12/17/2004 06:23:01 PM:
> 
> Good afternoon, WebDAV wg.  I have a question about the interpretation
> of RFC 2518 -- I hope this is the right place to post it.  If there's
> a better list, please let me know, and I subjunctively would apologize
> for posting here.
> 
> I'm implementing a DAV server for a commercial product that exposes
> its content through various protocols, of which DAV is only one. 
> There is some concern that the DAV semantics for MOVE and COPY with
> the overwrite header set to T are too dangerious for our repository...
> if the destination is a collection, it may be dangerous to do the
> equivalent of a depth-infinity DELETE before the MOVE or COPY, as
> section 8.8.4 and 8.9.3 dictate, because resources within a collection
> may have additional metadata, like version histories and so forth, as
> well as the equivalent of dead properties (although they won't be
> exposed as such through our DAV server in the first release).
> 
> So, I have two questions:
> 
> 1. given that overwriting a collection can have repurcussions for dead
> properties and so forth in general, why are MOVE and COPY defined as
> deleting the collections instead of (for example) a recursive
> per-resource overwrite that would retain properties on corresponding
> resources and remove those resources that were not in the source
> folder?
> 
> 2. would refusing to service MOVE or COPY requests, regardless of the
> value of the Overwrite header, when the destination is a non-null
> collection resource (responding, for example, with a 405 Method Not
> Allowed to such requests), be compliant with the RFC, or would it
> conflict with the rules in section 8.8.4 and 8.9.3?
> 
> Thanks.
>