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

LOCK Scenarios

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Thu, 5 Aug 1999 16:54:57 -0400
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243D9@crte147.wc.eso.mc.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
We've been concerned about interactions between MOVE and locks.  Logically
speaking, I think we have to consider the following cases.  (They are not
all equally realistic, but they all are possible.)  The question to answer
about each one is whether it seems right for the resource to be locked after
the MOVE, and if so, which lock should apply to it after the MOVE.

Considering these cases *may* help us decide whether the design principles
applied in RFC 2518 were the right ones.  Speaking for myself, I find that I
don't have clear and consistent reactions to these cases, so I find myself
relying on other considerations like what our underlying models imply, and
implementation considerations.

Anyhow, here are the cases:

In all cases, we assume that the agent requesting the MOVE owns all the
locks in question.

A resource is being MOVEd.  The locks are on that resource and / or its
destination, not the collections that contain them.

1. The source resource is locked, but the destination is not.
MOVE /a/b to /x/y, where /a/b is locked  but /a/ is not and /x/y is not.

2. The source resource is not locked, but the destination is.
MOVE /a/b to /x/y, where /a/b is not locked and /x/ is not locked, but /x/y
is locked

3. Both are locked, but with separate locks.
MOVE /a/b to /x/y, where /a/b has lock L1 and /x/y has lock L2, but neither
/a/ nor /x/ is locked.

A resource is being MOVEd.  The locks are Depth: infinity locks on the
collections that contain either the source or the destination location.

4. The source collection is locked, but the destination collection is not
MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not.

5. The source collection is not locked, but the destination collection is.
MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/
is locked.

6. Both are locked, but with separate locks.
MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2.

One lock is at the collection level, the other at the resource level.

7. The source resource is locked, and the destination collection is locked
with a different token
MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has
lock L2. 

8. The source collection is locked, the destination resource (not its
collection) is locked with a different token
MOVE /a/b ro /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has
lock L2.

For the following cases, should the MOVE succeed or fail? If it succeeds,
what should the lock state be afterwards?

9. The source resource was locked through one mapping, and a MOVE is
attempted through a different mapping.
9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y.

9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to
/x/y.

10. The destination resource was locked through one mapping, and a MOVE is
attempted through a different mapping.
10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z.

10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to
/y/z.


--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580
Received on Thursday, 5 August 1999 16:55:04 GMT

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