- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 5 Mar 2003 21:34:21 +0100
- To: "Brian Korver" <briank@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 9:06 PM > To: 'WebDAV' > Subject: 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 I guess you meant to say "move" here. > 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). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 5 March 2003 15:34:29 UTC