On Sun, Oct 18, 2009 at 09:50:25PM +0200, Stefan Fritsch wrote:
On Thursday 15 October 2009, Dick Davies wrote:
In any event, does it made sense to use something other than the
inode as the key into the lockDB - the URI for example?
Is the performance improvement of inode keyed locking so
On Sun, Oct 18, 2009 at 8:50 PM, Stefan Fritsch s...@sfritsch.de wrote:
On Thursday 15 October 2009, Dick Davies wrote:
In any event, does it made sense to use something other than the
inode as the key into the lockDB - the URI for example?
Is the performance improvement of inode keyed
On Thursday 15 October 2009, Dick Davies wrote:
In any event, does it made sense to use something other than the
inode as the key into the lockDB - the URI for example?
Is the performance improvement of inode keyed locking so large that it
is worth the hassle? If mod_dav_fs used filename keyed
[sorry for the crosspost, but not sure where this should go].
To answer my own question:
got to the bottom of it; looks to me like the
lock DB is a hash of
inode - locktoken
Steps to reproduce:
* PUT file
* LOCK file
* PROPGET file (note down the locktoken)
use something other than DAV to
On Thu, Oct 15, 2009 at 03:27:29PM +0100, Dick Davies wrote:
[sorry for the crosspost, but not sure where this should go].
To answer my own question:
got to the bottom of it; looks to me like the
lock DB is a hash of
inode - locktoken
Steps to reproduce:
* PUT file
* LOCK file
*
Is that documented anywhere at all?
In any event, does it made sense to use something other than the
inode as the key into the lockDB - the URI for example?
On Thu, Oct 15, 2009 at 3:33 PM, Joe Orton jor...@redhat.com wrote:
Steps to reproduce:
* PUT file
* LOCK file
* PROPGET file (note
Hi all
I'm on apache 2.0.63, and seeing nonsensical Dav Locks
(symptoms are that files show as being locked by users that couldn't
possibly have locked them).
I *think* I've tracked it down to a bug in mod_dav_fs; it appears that
if files are deleted
from disk (by a mechanism other than Dav),
