On Mon, Jun 14, 1999 at 10:07:36PM +0200, Andreas J. Koenig wrote:
>
> Here is a fix. Berkeley 1.85 tolerates this call with arg NULL, but
> the 2.7.5 compatibility mode doesn't.
> 
<snip>

Thanks Andreas, patch applied.

With regard to your question, why we switched to the outdated (and
potentially buggy) libdb1.85, instead of libdb2, there are several
reasons.

Initially, the pdbtool was built around gdbm, as it was already used
in other places within Coda. However, the current replication mechanism
for the volume and user databases, which is simply copying them from the
SCM to all other servers, didn't work. The *BSD machines couldn't read
the databases written by Linux/WinXX machines, and vice versa.

So we needed to either create our own fileformat or switch to a database
that did allow us to blindly copy the db-files. (Actually we really need
a better way for managing and replicating the volume and user data). Both
libdb and libdb2 can survive the copying, even wrt. to big and little
endian machines. But, libdb1.85 is integrated in the *BSD's libc library,
and because of libdb2's licensing policy, it is normally only available
on platforms that use glibc, or where someone has actually taken the time
to install it.

We actually use only a small subset of the libdb functionality, so I
optimistically expect not to hit too many of the virtualy unfixable bugs.

The libdb emulation in libdb2 is API-compatible, so everything should work
normally, (besides the coredump you've just fixed). But the on-disk format
is not, which limits its useability to only having a replicated group of
servers that all use libdb2 to store the files generated by pdbtool.

Thanks for the fiddling,
    Jan