On Thu, 29 May 1997, Jason S Kohles wrote:
> I had problems with database corruption when I first installed exim on my
> little linux box, and it turns out that what happened was, berkeley db comes
> with some header files that you are supposed to install, including ndbm.h,
> I put all these headers into /usr/local/include, and libdb.a into
> /usr/local/lib. What caused the problem was that exim was using an older
> copy of ndbm.h that came with the linux distribution and resided in
> /usr/include, so it was being found first. I renamed the old ndbm.h to
> ndbm.h.old, rebuilt exim, and now everything works perfectly...
I am spending some time working on the support for the various different
DB implementations that are around, and one of the results will be some
better documentation about the various gotchas involved. I can confirm
what Jason says above, and add the following:
This applies only when using Berkeley DB 1.85 via the ndbm compatibility
interface. If you set USE_DB in your Local/Makefile to use the native
Berkeley interface, the problem does not arise. That is why we haven't
seen any problems on our machines here in Cambridge that use Berkeley
DB.
The actual bug is insidious. The ndbm interface has a macro for getting
a file descriptor for the purpose of locking. It seems that, if the
wrong version of ndbm.h is used, this macro is likely to return a small
integer that is a valid file descriptor, but not the correct one.
Consequently, the locking appears to work, but in fact the database has
not been locked at all, and is therefore liable to corruption.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
