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.

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

Received on Sunday, 9 March 2003 12:18:48 UTC