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

can't delete a locked file over ra_dav

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-24 23:04:39 CET

I've got a nasty bug here, hoping gstein can step in and clarify.

The scenario is simple: I'm trying to commit the deletion of a
locked-file. The error I get back is from mod_dav, about a failed

$ svn commit
Deleting svn_time.h
subversion/libsvn_client/commit.c:781: (apr_err=175002)
svn: Commit failed (details follow):
subversion/libsvn_ra_dav/util.c:295: (apr_err=175002)
svn: DELETE of
424 Failed Dependency (http://localhost)

[Thu Mar 24 14:47:54 2005] [error] [client ::1] Could not DELETE
/svn/repos/!svn/wrk/e862d013-15f3-0310-9442-c7150e0dcd1c/svn_time.h due
to a failed precondition (e.g. locks). [424, #0]

The http requests being sent are straightforward: we do a MKACTIVITY,
then CHECKOUT the parent directory (and get back a working collection
resource), then do a DELETE of the file (expressed as a working
resource, an assumed direct child of the working collection). The
DELETE request has a normal lock-token header:

    If: (<opaquelocktoken:7dc005f9-14f3-0310-bd42-8a5c1c1ed0de>)

I've stepped through the logic of dav_method_delete() in gdb, and I'm
perplexed by what I see on multiple levels.

        1. dav_method_delete() calls dav_validate_request(), asking that
           the parent be validated as well. (why validate the parent?)

        2. the If: header is parsed, and dav_validate_resource_state()
           runs on the original resource, checking that incoming
           matches the file's lock.

        3. dav_validate_resource_state() is called on the parent
           resource, using the same If: header. (why the *same* If:

             From here, it tries to compare parent-locks with the
             If: header. There are no parent-locks, so it returns
failure (!?!?)

So up till now, I've always thought of the 'If: (token)' header as a
sort of pre-emptive response to an expected authn challenge. "Here's
my token, you'll probably need it when you see that the resource is

But it seems like that's not the case at all: mod_dav treats the If:
header as something that *must* be matched. In other words, if I
invent a phony token and attach it to a PUT request, the request will
fail if the resource is unlocked! Is that correct?

In any case, assuming this is true... why on earth is mod_dav trying to
validate both the resource *and* its parent using the same If: header?

Can this problem be fixed by having libsvn_ra_dav send requests

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 24 23:07:45 2005

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.