RE: Could not LOCK /source/index.htm due to a failedprecondition (e.g. other locks).
David Cake <dave <at> difference.com.au>
2005-08-03 00:29:43 GMT
At 8:02 AM -0700 1/8/05, Bennett, Tony - CNF wrote:
>> Trying to access webDAV on apache 1.3.33 on debian stable,
>> trying both Mac OS X 10.4 and windows xp clients.
>> I appear to be able to access webDAV fine for reading files,
>> but when I try to save changes to a file I get an error (a -47 error
>> on the mac) and
>> [Fri Jul 29 01:58:12 2005] [error] [client 220.127.116.11] Could not
>> LOCK /source/index.htm due to a failed precondition (e.g. other
>> locks). [423, #0]
>> [Fri Jul 29 01:58:12 2005] [error] [client 18.104.22.168] Existing
>> lock(s) on the requested resource prevent an exclusive lock. [423,
>> in the logs.
>> My DAVLock file looks to have the right permissions to me,
>> and the files are definitely readable and writable by my web servers
>> user/group . Any other ideas?
>Your original posting doesn't seem to be "asking a question"...
>...although the emplied question was that you thought you didn't have
>Mod_dav configured correctly.
Well, lets take the implied question as the behaviour I show
is undesirable, and I'd like it not to happen - I assume its a
mod_dav issue, but thats just a working hypothesis. I'm no longer
sure its true, I may just have a one-off problem created due to a
user crashing at a crucial point or similar.
>In a prior posting, I noted that the apache log messages you included
>Indicated another application had the resource (/source/index.htm)
>Locked, and returned a failure on a PUT. Further I posted that if
>You wanted to discover additional information about the lock, you
>could use cadaver. And if the LOCK is a remnant of an application
>That has exited without unlocking it, you could use Cadaver to
>"steal" the lock, and then unlock the resource with it.
OK, after a bit of experimentation, my new question becomes -
- I can steal the token, but not unlock with it, as I am not the same
user that created it
- so I get a User "dave" submitted a locktoken created by user
"user". [403, #0]
Is there a way to clear this up without getting the users login info?
Or otherwise ensure the resource is unlocked.