Subject: Re: Atomic MOVE and move permissions

From: Jason Crawford <[email-masked]>
Date: Sat, 8 Mar 2003 16:09:27 -0500

> 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,   [email-masked]
I do not check [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 9 Mar 2003 09:18:45 -0800

> status code is not sensitive to how the subsequent cleanup goes.

OK, now we're getting to pinpoint our different assumptions. Do you
assume it's better for the server to do the atomic remap, return
"success", and worry about cleanup later?  That's valid for some
servers, certainly. If there are "orphaned" resources, the administrator
can clean them up later.

However, that assumption isn't valid for all servers. For a server like
Sharemation, we count each file stored against some user's quota. If a
collection MOVE or DELETE fails, and we can't free up that quota, we
need to let the user know so they can fix it up.  It's quite possible
the user will be able to fix up the operation by removing locks, getting
permissions changed, or simply trying again.

Finally, the server needs to consider if rollback is feasible or
desirable.  In theory, it would be reasonable to say that servers SHOULD
succeed 100%, or failing that SHOULD rollback 100%, or only if both
those fail should the server report a partial success. That's not the
model WebDAV has had so far, however. So that might be a reasonable
position for the bindings specification to take but I'm not sure people
would support changing RFC2518 in that manner.

Lisa