According to the Postfix HISTORY file:
20021031
Portability: support for Berkeley DB version 4.1. This
version refuses to open zero-length files. This complicates
lock management and requires extra code to remove broken
files. Files: util/dict_db.c, global/mkmap*.[hc].
So, you can choose to live on the bleeding edge, or you can use an
earlier Berkeley DB version.
Wietse
Ralf S. Engelschall:
> Keith and Wietse,
>
> the latest Berkeley DB 4.1.24 causes big trouble for some applications
> like Postfix, Sendmail, etc. We encountered this recently when we
> upgraded the OpenPKG (http://www.openpkg.org/) package for Berkeley
> DB from 4.0.14 to 4.1.24. First, the API changes to DB->open() are
> harmless. A little bit of patching (adding a zero for the extra
> argument) made the applications building against DB 4.1.24 just fine.
> But there is a more subtle second problem:
>
> As it looks, DB 4.1.24 does no longer accept empty database files,
> i.e., if an application touches the xx.db file before opening it, DB
> complains. In older versions this just worked fine. Unfortunately many
> applications out there (including Postfix and Sendmail) create the
> zero-size xx.db file theirself. Postfix for instance in order to do
> own exclusive locking on this file, etc. And we've not found any way
> to force DB 4.1.24 to not complain in this situation. Have we missed
> something?
>
> Sure, one can argue that DB 4.1.24 is free to complain here and that
> applications should not do own locking or other fiddling with the .db
> files. OTOH applications do it for various reasons: locking, forcing
> permissions or ownerships, etc. And fact is that the latest DB 4.1.24
> breaks all those applications. So my recommendation to you two is
> two-fold:
>
> 1. Keith, please make this "complain on empty pre-created .db file"
> _optional_. You can still make the default to complain, but please
> provide at least an option to force DB to overwrite zero-size .db
> files. This way the transition/patching of existing applications get
> easier and you still support the fiddling with .db files if really
> wished by the application.
>
> 2. Wietse, please try to cleanup the src/global/mkmap* and
> src/util/dict_db.c code. Especially the locking logic is spread
> over the whole code and it is currently not easy to get Postfix to
> work-around the problem. I even would try to allow Berkeley DB to the
> locking itself (at least in latest versions). My hack today to get
> Postfix 1.1.11 "just working" with DB 4.1.24 without having to axe
> out many things in Postfix was to just lock the source ("xx") instead
> of the target ("xx.db") files. Else "postmap" would never be able to
> create .db files at all. But, yes, I do not post you a patch, because
> this is just a kludge to get it "just working". The real solution for
> Postfix is to either explicitly support dedicated lockfiles (e.g.
> "xx.lock") or at least perform the zero-size pre-generated of .db
> files not or DB 4.1 and higher. Or wait for Keith introduce a new
> flag for DB->open to force DB to accept the empty .db files ;)
>
> Hopefully you are open minded to these suggestions. At least please
> recognize that currently DB 4.1.24 fully breaks many popular
> applications and that some them (like Postfix) are not easily fixable
> (because for various reasons require or wish some direct .db fiddling in
> their internal logic).
>
> Thanks for listening and keep up your good work!
>
> Yours,
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
>
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
