httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: svn commit: r834049 - in /httpd/httpd/trunk: CHANGES modules/dav/fs/lock.c modules/dav/fs/repos.c
Date Mon, 09 Nov 2009 13:42:21 GMT
On Monday 09 November 2009, Greg Stein wrote:
> On Mon, Nov 9, 2009 at 08:14,  <sf@apache.org> 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?

Mime
View raw message