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

> 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