You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Pauli Ojanperä <pa...@jyu.fi> on 2009/10/05 15:19:36 UTC
The Big Lie : if (info->r->method_number == M_LOCK) BUG?
Hello!
I was investigating a Subversion locking bug reported here:
http://svn.haxx.se/users/archive-2009-07/0169.shtml
My own experience of the bug tells that any tries of a MS Office application
to refresh its lock do fail. By running "svnadmin lslocks repo" we can
confirm that the initial locking succeeds. However, mod_dav is not getting
the information of the lock token's existence, and fails on the "If:"
precondition manifested in the lock refresh request header.
Apache logs say:
Could not LOCK /repo/nnn.txt due to a failed precondition (e.g. other
locks). [412, #0]
The precondition(s) specified by the "If:" header did not match this
resource. At least one failure is because: a State-token was supplied, but
it was not found in the locks on this resource. [412, #0]
It seems to me that the commit linked below causes mod_dav_svn to be
unable to confirm the precondition (the existence of a locktoken) to
continue fulfilling a lock refresh request.
http://svn.collab.net/viewvc/svn/trunk/subversion/mod_dav_svn/lock.c?r1=19508&r2=19509&
What do you think?
Pauli
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403724
Re: The Big Lie : if (info->r->method_number == M_LOCK) BUG?
Posted by Pauli V <pa...@jyu.fi>.
Okay, the issue has been reported:
http://subversion.tigris.org/issues/show_bug.cgi?id=3515
Pauli
> [Returning the discussion to the devlist where it belongs.]
>
> Thanks for the info. It's been a while since I worked on our WebDAV
> autoversioning logic. I *definitely* don't have a new enough version of
> Web
> Folders available. (My personal boxen still run Win2k!) I think you've
> given me enough reason to believe there's a real problem to be researched
> here, so please feel free to file an issue in our issue tracker regarding
> this problem (at http://subversion.tigris.org/issue-tracker.html).
>
> I trust that by "you may receive", you mean "you, the dev-list, may
> receive". You might not always get immediate response from the dev-list,
> but the beauty of a mailing list is that your information is maintained
> indefinitely for future archaeological benefit. Many of us flag incoming
> mails for processing later, as there's always the chance that someone else
> can spend the time to respond right now even if we really can't.
>
>
> Pauli Vaahterametsä wrote:
>> Hi,
>>
>> Yes. The default lock timeout is 3 minutes and in about 2 minutes Word
>> will try to refresh the lock and fail, and the open document will change
>> into a read only mode.
>>
>> Of course you should have a recent (12.x, Rosebud) version of Web
>> Folders
>> installed before trying to use MS Office for any real WebDAV debugging
>> operations. The problem should exist also with earlier versions though,
>> as
>> I see it as a server side problem.
>>
>> If you have difficulties reproducing the problem I can provide all
>> information you need. I'm running the server on a Win32 platform.
>>
>> (Btw, now that I've gotten a communication contact to someone there, you
>> may receive many other bug reports in the future. :-) )
>>
>> Pauli
>>
>>> Pauli, is reproducing the problem you are seeing as simple as, say,
>>> opening
>>> a Word document directly from a Subversion DAV share and letting it sit
>>> for
>>> some amount of time greater than the originally request lock timeout
>>> value?
>>>
>>> Pauli Ojanperä wrote:
>>>> Hello!
>>>>
>>>> I was investigating a Subversion locking bug reported here:
>>>> http://svn.haxx.se/users/archive-2009-07/0169.shtml
>>>>
>>>> My own experience of the bug tells that any tries of a MS Office
>>>> application
>>>> to refresh its lock do fail. By running "svnadmin lslocks repo" we can
>>>> confirm that the initial locking succeeds. However, mod_dav is not
>>>> getting
>>>> the information of the lock token's existence, and fails on the "If:"
>>>> precondition manifested in the lock refresh request header.
>>>>
>>>> Apache logs say:
>>>> Could not LOCK /repo/nnn.txt due to a failed precondition (e.g. other
>>>> locks). [412, #0]
>>>> The precondition(s) specified by the "If:" header did not match this
>>>> resource. At least one failure is because: a State-token was supplied,
>>>> but
>>>> it was not found in the locks on this resource. [412, #0]
>>>>
>>>> It seems to me that the commit linked below causes mod_dav_svn to be
>>>> unable to confirm the precondition (the existence of a locktoken) to
>>>> continue fulfilling a lock refresh request.
>>>>
>>>> http://svn.collab.net/viewvc/svn/trunk/subversion/mod_dav_svn/lock.c?r1=19508&r2=19509&
>>>>
>>>> What do you think?
>>>>
>>>> Pauli
>>>>
>>>> ------------------------------------------------------
>>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403724
>>>
>>> --
>>> C. Michael Pilato <cm...@collab.net>
>>> CollabNet <> www.collab.net <> Distributed Development On
>>> Demand
>>>
>>>
>>
>>
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2411635
Re: The Big Lie : if (info->r->method_number == M_LOCK) BUG?
Posted by "C. Michael Pilato" <cm...@collab.net>.
[Returning the discussion to the devlist where it belongs.]
Thanks for the info. It's been a while since I worked on our WebDAV
autoversioning logic. I *definitely* don't have a new enough version of Web
Folders available. (My personal boxen still run Win2k!) I think you've
given me enough reason to believe there's a real problem to be researched
here, so please feel free to file an issue in our issue tracker regarding
this problem (at http://subversion.tigris.org/issue-tracker.html).
I trust that by "you may receive", you mean "you, the dev-list, may
receive". You might not always get immediate response from the dev-list,
but the beauty of a mailing list is that your information is maintained
indefinitely for future archaeological benefit. Many of us flag incoming
mails for processing later, as there's always the chance that someone else
can spend the time to respond right now even if we really can't.
Pauli Vaahterametsä wrote:
> Hi,
>
> Yes. The default lock timeout is 3 minutes and in about 2 minutes Word
> will try to refresh the lock and fail, and the open document will change
> into a read only mode.
>
> Of course you should have a recent (12.x, Rosebud) version of Web Folders
> installed before trying to use MS Office for any real WebDAV debugging
> operations. The problem should exist also with earlier versions though, as
> I see it as a server side problem.
>
> If you have difficulties reproducing the problem I can provide all
> information you need. I'm running the server on a Win32 platform.
>
> (Btw, now that I've gotten a communication contact to someone there, you
> may receive many other bug reports in the future. :-) )
>
> Pauli
>
>> Pauli, is reproducing the problem you are seeing as simple as, say,
>> opening
>> a Word document directly from a Subversion DAV share and letting it sit
>> for
>> some amount of time greater than the originally request lock timeout
>> value?
>>
>> Pauli Ojanperä wrote:
>>> Hello!
>>>
>>> I was investigating a Subversion locking bug reported here:
>>> http://svn.haxx.se/users/archive-2009-07/0169.shtml
>>>
>>> My own experience of the bug tells that any tries of a MS Office
>>> application
>>> to refresh its lock do fail. By running "svnadmin lslocks repo" we can
>>> confirm that the initial locking succeeds. However, mod_dav is not
>>> getting
>>> the information of the lock token's existence, and fails on the "If:"
>>> precondition manifested in the lock refresh request header.
>>>
>>> Apache logs say:
>>> Could not LOCK /repo/nnn.txt due to a failed precondition (e.g. other
>>> locks). [412, #0]
>>> The precondition(s) specified by the "If:" header did not match this
>>> resource. At least one failure is because: a State-token was supplied,
>>> but
>>> it was not found in the locks on this resource. [412, #0]
>>>
>>> It seems to me that the commit linked below causes mod_dav_svn to be
>>> unable to confirm the precondition (the existence of a locktoken) to
>>> continue fulfilling a lock refresh request.
>>>
>>> http://svn.collab.net/viewvc/svn/trunk/subversion/mod_dav_svn/lock.c?r1=19508&r2=19509&
>>>
>>> What do you think?
>>>
>>> Pauli
>>>
>>> ------------------------------------------------------
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403724
>>
>> --
>> C. Michael Pilato <cm...@collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
>>
>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2405671
Re: The Big Lie : if (info->r->method_number == M_LOCK) BUG?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Pauli, is reproducing the problem you are seeing as simple as, say, opening
a Word document directly from a Subversion DAV share and letting it sit for
some amount of time greater than the originally request lock timeout value?
Pauli Ojanperä wrote:
> Hello!
>
> I was investigating a Subversion locking bug reported here:
> http://svn.haxx.se/users/archive-2009-07/0169.shtml
>
> My own experience of the bug tells that any tries of a MS Office application
> to refresh its lock do fail. By running "svnadmin lslocks repo" we can
> confirm that the initial locking succeeds. However, mod_dav is not getting
> the information of the lock token's existence, and fails on the "If:"
> precondition manifested in the lock refresh request header.
>
> Apache logs say:
> Could not LOCK /repo/nnn.txt due to a failed precondition (e.g. other
> locks). [412, #0]
> The precondition(s) specified by the "If:" header did not match this
> resource. At least one failure is because: a State-token was supplied, but
> it was not found in the locks on this resource. [412, #0]
>
> It seems to me that the commit linked below causes mod_dav_svn to be
> unable to confirm the precondition (the existence of a locktoken) to
> continue fulfilling a lock refresh request.
>
> http://svn.collab.net/viewvc/svn/trunk/subversion/mod_dav_svn/lock.c?r1=19508&r2=19509&
>
> What do you think?
>
> Pauli
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403724
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2405217