On Mon, Nov 9, 2009 at 08:42, Stefan Fritsch <[email protected]> wrote: > On Monday 09 November 2009, Greg Stein wrote: >> On Mon, Nov 9, 2009 at 08:14, <[email protected]> wrote: >> > Author: sf >> > Date: Mon Nov 9 13:14:07 2009 >> > New Revision: 834049 >> > >> > URL: http://svn.apache.org/viewvc?rev=834049&view=rev >> > Log: >> > Make PUT with DAV_MODE_WRITE_TRUNC create a temporary file first >> > and, when the transfer has been completed successfully, move it >> > over the old file. >> > >> > Since this would break inode keyed locking, switch to filename >> > keyed locking exclusively. >> > >> > PR: 39815 >> > Submitted by: Paul Querna, Stefan Fritsch >> > >> > Modified: >> > httpd/httpd/trunk/CHANGES >> > httpd/httpd/trunk/modules/dav/fs/lock.c >> > httpd/httpd/trunk/modules/dav/fs/repos.c >> > >> > Modified: httpd/httpd/trunk/CHANGES >> > URL: >> > http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=834049 >> >&r1=834048&r2=834049&view=diff >> > ================================================================= >> >============= --- httpd/httpd/trunk/CHANGES [utf-8] (original) >> > +++ httpd/httpd/trunk/CHANGES [utf-8] Mon Nov 9 13:14:07 2009 >> > @@ -10,6 +10,13 @@ >> > mod_proxy_ftp: NULL pointer dereference on error paths. >> > [Stefan Fritsch <sf fritsch.de>, Joe Orton] >> > >> > + *) mod_dav_fs: Make PUT create files atomically and no longer >> > destroy the + old file if the transfer aborted. PR 39815. >> > [Paul Querna, Stefan Fritsch] + >> > + *) mod_dav_fs: Remove inode keyed locking as this conflicts >> > with atomically + creating files. This is a format cange of >> > the DavLockDB. The old + DavLockDB must be deleted on >> > upgrade. [Stefan Fritsch] + >> > *) mod_log_config: Make ${cookie}C correctly match whole cookie >> > names instead of substrings. PR 28037. [Dan Franklin <dan >> > dan-franklin.com>, Stefan Fritsch] >> >... >> >> Why did you go with a format change of the DAVLockDB? It is quite >> possible that people will miss that step during an upgrade. You >> could just leave DAV_TYPE_FNAME in there. > > That wouldn't help because it would still break with DAV_TYPE_INODE > locks existing in the DAVLockDB. Or am I missing something?
Heh. Yeah. I realized that right *after* I hit the Send button :-P Tho: mod_dav could error if it sees an unrecognized type, rather than simply misinterpreting the data and silently unlocking all nodes. Cheers, -g
