W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

Re: Bindings, Locks, and MOVE

From: Greg Stein <gstein@lyra.org>
Date: Wed, 08 Sep 1999 13:08:03 -0700
Message-ID: <37D6C223.1FDAB5F1@lyra.org>
To: "Slein, Judith A" <JSlein@crt.xerox.com>
CC: w3c-dist-auth@w3.org
Slein, Judith A wrote:
> 
> The intention is that if a resource is copied or moved into a tree that is
> locked, the lock on the tree remains in force.
> 
> We didn't discuss the case where you are doing a MOVE, and the resource
> being moved is locked, and it is being moved into a collection that is
> locked.  The lock on the collection will certainly stay in force, but we
> need to decide whether the lock on the resource being MOVEd will be lost or
> whether the MOVE will fail.  I guess my own opinion is that the MOVE should
> fail, since that maintains a consistent position that the state of a MOVEd
> resource should be unaffected by the move; if its lock state would have to
> be changed, the move should fail.

There is a third case: allow the move. How about this: allow the MOVE,
the resource then falls under the Destination lock, the source is now in
a lock-null state.

Therefore, the user does *not* lose any locks, the MOVE is completed,
and this scenario actually provides a way to do a "safe" MOVE. If the
user could not lock both ends, then you have a race condition. Further,
making the user lock the source "one level up" so that the lock wouldn't
move with the resource just feels like a hack.

If you are MOVEing a collection and there is a lock on one of the
collection members, then the move should fail if there is an
incompatible lock (e.g. exclusive and not the same lock) at the
destination.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/
Received on Wednesday, 8 September 1999 16:17:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:51 GMT