Re: Atomic MOVE and move permissions

> But back to the atomic vs. non-atomic move, the permissions example was
> just an example.  You still have to recursively check privileges on all
> descendent _collections_ if one accepts your permissions model.  And you
> still have to recursively check locks, etc.  The basic argument for
> non-atomic move was that in some situations, the server will have to
> implement it as a super-user COPY-->DELETE.

Again... even in situations where it has to implement it under the
covers as a DELETE(dest)/COPY/DELETE(src), it can still be
atomic or nearly so because it can be backed out up to and including
the atomic remap.  After that it's committed and the WebDAV MOVE's
response's
status code is not sensitive to how the subsequent cleanup goes.


> Right, but did you read the part about how the server might be able to
> do a much better job of the under-the-cover copy-and-delete than the
> client possibly could?  A client can only do operations based on its
> authenticated context, whereas the server process may have more power to
> change things.  My first example, and it's only one of many, was that a
> client may not have permission to set "creationdate" but a server
> obviously can.  So if the server accomplishes the MOVE by doing a
> copy-and-delete behind the scenes, the server can clean up
> "creationdate" so that it's the date of the original resource. However,
> the client may not be allowed to set the value of "creationdate" to the
> most correct value after it does a manual COPY operation.

Right, if it fails, the client needs to evaluate what it was trying to
achieve.
It is possible that it has no acceptable recourse.

Even for the atomic version, we should insure that our responses are
descriptive enough that the client can understand why the MOVE or DELETE
failed.


------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

Received on Saturday, 8 March 2003 16:14:06 UTC