- From: Brian Korver <briank@xythos.com>
- Date: Wed, 5 Mar 2003 13:48:27 -0800
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
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