(Illustration by Gaich Muramatsu)
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, JanReceived on 1999-06-15 23:24:05