httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
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 20:23:49 GMT
On Mon, Nov 9, 2009 at 15:21, Greg Stein <gstein@gmail.com> wrote:
> On Mon, Nov 9, 2009 at 14:46, Stefan Fritsch <sf@sfritsch.de> 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.

To clarify this comment I made:

> If
> the sysadmin missed the "erase your db" step, then there will be a
> silent failure (locks will be missed).

I mean: using the *current* code, as checked-in, there will be a
silent failure to recognize old/outstanding locks.

I think it would be best for us to at least say "woah. you didn't read
the instructions. go RTFM." The admin can then decide to blast the
lockdb, or avoid the upgrade. Their choice.

Cheers,
-g

>
>> 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.
>
>> 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."
>
> Cheers,
> -g
>

Mime
View raw message