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

On Wednesday, March 5, 2003, at 12:21  AM, Julian Reschke wrote:
> 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

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
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?
       What is the point of this extra round trip?

-brian
briank@xythos.com

Received on Wednesday, 5 March 2003 15:06:29 UTC