- From: Brian Korver <briank@xythos.com>
- Date: Wed, 5 Mar 2003 12:06:00 -0800
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
- Message-Id: <E27033AA-4F45-11D7-8A8F-000393751598@xythos.com>
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