Re: Bindings, Locks, and MOVE

   From: "Slein, Judith A" <JSlein@crt.xerox.com>

   I like everything that you say here, but the MOVE / COPY TO cases raise a
   red flag for me.  We claim in the bindings spec that the MOVE semantics we
   present  is equivalent to the COPY + fixup + DELETE semantics defined in RFC
   2518.  But I doubt it when I look at this case.

<gmc/> The author of the statement that "MOVE is logically equivalent
to COPY+fixup+DELETE" (who will remain nameless although we all know
who he is :-) has publicly renounced this statement.  The problem of
course is the wonderfully undefined "fixup" stage.  *ANY* semantics is
acceptable for MOVE, for some definition of "fixup".  So let's see if
all is well for this case with some suitably defined value of "fixup".

   Leave aside for a minute intuitions about what should really happen, and
   just see what would follow from the underlying semantic model:

   Suppose we define MOVE as "remove the binding identified by the Request-URI
   and add the binding identified by the Destination header".

   Now consider your case: /a/b.html and /x/y.html both point to resource R,
   and I have an exclusive write lock on /a/b.html.  User2 tries to MOVE
   /c/d.html (which points to some other resource S) to /x/y.html.  It seems
   this should be possible, because all that is happening is that the binding
   y.html in collection /x/ is being replaced with one that binds to a
   different resource.  Nothing happens to resource R.

   But if we use the COPY + fixup + DELETE semantics for MOVE, resource S would
   have to be duplicated, overwriting R.  And this would not be allowed,
   because R is locked.

<gmc/> It doesn't overwrite R.  A COPY to an existing resource will
either fail (if Overwrite=FALSE) or issue a DELETE on the destination
of the COPY.  The DELETE of /x/y.html succeeds just fine (since DELETE
is properly defined to just remove the binding named "y.html" from the
collection "/x"), the COPY proceeds, and then the "fixup" step
replaces the binding to the new resource created by the COPY with a
binding to R, and then a DELETE is issued on the request URL of the
MOVE, which then deletes the binding named "d.html" from the
collection "/c".

   Of course, we can legislate this problem away by, for example, accepting
   your proposal that a MOVE or COPY like this one fail no matter which
   semantics you use.  But I'm afraid other cases will turn up that reveal
   inconsistencies between the 2 models of MOVE.

<gmc/> I believe there are no inconsistencies here ... just suitably creative
definitions of "fixup" (:-).

Cheers,
Geoff

Received on Wednesday, 15 September 1999 12:56:23 UTC