Sorry for missing earlier messages; I don't follow httpd as closely as before.
See my replies below: On Mon, Nov 9, 2009 at 06:28, Stefan Fritsch <s...@sfritsch.de> wrote: > On Friday 23 October 2009, Stefan Fritsch wrote: >> On Thursday 22 October 2009, Joe Orton wrote: >> > > Is the performance improvement of inode keyed locking so large >> > > that it is worth the hassle? If mod_dav_fs used filename keyed >> > > locking entirely, there would be an easy way to make file >> > > replacement by PUT atomic (see PR 39815). The current behaviour >> > > of deleting the old and the new file when the PUT fails is >> > > really bad. >> > >> > I believe the intent of using inode/device-number keyed locks was >> > to ensure that the lock database is independent of the mount >> > point - i.e. you could move it around in the filesystem and it'd >> > still work. No, I don't think so. The database would be movable with or without inodes, afaik. That is dim history :-P, but I am pretty it is because I was looking forward to when the BIND protocol was implemented and you could bind multiple URLs to the same resource. Thus, if you wanted to lock the *resource*, then the inode was your primary key. Locking one path and allowing changes through another would be Badness. >... [snip: bad PUT behavior] ... > > Since nobody disagreed, I am going ahead with this and remove inode > keyed locks and make PUT use temp files. > > Using temp files and inode keyed locks would require to either copy > (instead of move) the temp file to the target file, or to extend the > dav_hooks_locks interface. I think both solutions are worse than just > switching to file name keyed locks. People aren't running around with symlinks in their repository, I believe. mod_dav is pretty unaware of them, and Bad Things are advertised to happen. It already takes some steps to explicitly disallow symlinks as "files". Thus, the notion of one resource in two locations is probably moot. Therefore, improving the PUT situation rather than keeping inodes is a very good tradeoff. Thanks, -g
