httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: svn commit: r834049 - in /httpd/httpd/trunk: CHANGES modules/dav/fs/lock.c modules/dav/fs/repos.c
Date Tue, 10 Nov 2009 16:03:51 GMT
On Monday 09 November 2009, Greg Stein wrote:
> On Mon, Nov 9, 2009 at 14:46, Stefan Fritsch <> wrote:
> > On Monday 09 November 2009, Greg Stein wrote:
> >> >> 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.
> >
> > What do you want to do exactly? Check the db at httpd startup and
> > abort if it contains old format entries? I don't think it is
> > possible to convert the entries, at least not without traversing
> > the whole dav tree.
> Oh dear, no. I was just thinking of dropping a log like, "cannot
>  open DAVLockDB at /some/path; it has old-style entries."
> That would effectively shut off DAV and leave a reason for why it
> happened. Quite enough for a sysadmin to figure out how to fix it.
>  If the sysadmin missed the "erase your db" step, then there will
>  be a silent failure (locks will be missed).

> > In any case, I wonder if this is worth the effort. It definitely
> > isn't
> Not suggest any more work than to revert the removal of the TYPE
>  byte from the lock record. Then add a simple check/error if the
>  type is not FNAME.

We would have to search through all the keys in the DB. This would 
mean that we have to read the whole lockdb on every server restart. 
This is quite a step from the current behaviour of only opening the 
lockDB when there actually is a lock request. I don't think this is 
what we want.

Not removing the TYPE byte would however mean that locknull locks are 
not lost and, more importantly, it would keep the db format unchanged 
on platforms that don't have inodes anyway. Therefore I agree that 
this is a good idea.

> > for 2.2 -> 2.4 upgrades. And if we backport the changes to 2.2.x,
> > I would still primarily see it as responsibility of the
> > distributors to warn the user/remove the old db in postinst/etc.
> >
> > And for those people who compile it themselves and run a system
> > critical enough that they cannot affort to loose the locks during
> > an httpd upgrade, those people should really read the changelog.
> Sure, but I'd rather make it a bit easier for them. We don't simply
> change directives on people without trying to do something
>  intelligent for when we see the old format. We never just say
>  "well, we'll silently misinterpret that. them's the breaks."

View raw message