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

On Wednesday, March 5, 2003, at 12:34  PM, Julian Reschke wrote:
>>
>> Julian,
>>
>> I don't think we can push this behavior out to the client.
>>
>> For the sake of illustration, let's take an hypothetical
>> repository built on a unix filesystem:
>>
>>    Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
>>    /dev/da0s1f    992239      372   912488     0%    /users/briank
>>    /dev/da0s1g   3048942  2509636   295391    89%    
>> /users/briank/MP3s
>>
>> Now, let's say I've got a file sitting at /users/briank/tmp/groovy.mp3
>> that I'd like to copy to my MP3s collection.  What is my WebDAV
>
> I guess you meant to say "move" here.

Oops.  Yes.


>
>> client going to do?  We have two cases:
>>
>>    1)  The server is "smart" and performs a copy/delete
>>
>>        Ok, in this case my client issues a MOVE, the server performs
>>        a copy/delete (NOT rename(2) [link/unlink]).  But notice, this 
>> is
>>        a server-side copy/delete, not client-side.
>>
>>    2)  The server isn't "smart" and thus the client must
>>        perform a COPY/DELETE
>>
>>        What happens here?  The client issues a MOVE, but this
>>        must fail because rename(2) doesn't work across file
>>        systems.  What error does the server return to tell
>>        the client that a COPY/DELETE must be performed instead?
>
> I guess we want a specific precondition failure that can be signaled. 
> For
> instance, DAV:preserve-versioning-properties.
>
>>        What is the point of this extra round trip?
>
> The same thing as the failure you'll get upon trying to rename. MOVE is
> *not* the same thing (or should not be the same thing) as COPY/DELETE. 
> If a
> MOVE can't preserve the resource's live properties, it should fail.
>
> Now I *do* agree that in many cases clients will actually *want* the 
> "weak"
> MOVE. So maybe we should consider supporting both (either by a new 
> method,
> or by adding parameters to MOVE).

That's an interesting idea.


-brian
briank@xythos.com

Received on Wednesday, 5 March 2003 16:48:29 UTC