[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: DAV locking question

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2004-11-04 15:39:35 CET

Ben Collins-Sussman wrote:
> On Nov 4, 2004, at 2:58 AM, Julian Reschke wrote:
>> Ben Collins-Sussman wrote:
>>> This question is mainly for Julian Reschke:
>>> If a DAV client locks a NULL resource (one that doesn't exist), is a
>>> parent directory deletable?
>> Two-part answer.
>> 1) RFC2518's special handling of "lock null" resources will be
>> deprecated in RFC2518bis. So absolutely no need to worry about special
>> cases. Treat them as locks on empty resources (as if a PUT with no
>> body was done immediately before the LOCK).
> I'm sort of confused here: are you suggesting that if a LOCK request
> comes in on an imaginary file path, that we (1) create an empty file,
> (2) create an entry in the locks-table? Or is it sufficient just to do
> (2)?

The former. In RFC2518bis, LOCK on a null resource is equivalent to a
sequence of PUT then LOCK on that URI.

>> 2) That being said; the parent directory will only be deletable if you
>> submit the lock token with the DELETE request (both with standard
>> locking semantics and the special cases defined by RFC2518 for "lock
>> null" resources).
> Okay, I think this was my original question. If process A locks an
> imaginary path, then process B tries to delete a parent dir *before*
> process A does a PUT, then process B's request should fail, right?
> That's what your explanation sounds like to me.

Yes, unless the lock token for the locked resource is submitted with the
DELLETE request.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 4 15:40:22 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.