[Date Prev][Date Next] [Chronological] [Thread] [Top]

More on ldbm_initialize in libraries/libldbm/ldbm.c

The home that is passed to ldbm_initialize (from back-ldbm/init.c) is
not yet initialized (ie. points to NULL), and therefore has no effect on
the underlying database calls.  However, your new routine,
ldbm_initialize_env, is called later to initialize DB3, with the a
different structure member (li->li_directory) that does contains the
home.  This has the unfortunate consequence of breaking the ldbm_open
calls in the tests, because relative directory paths are used in
slapd.conf (but only for DB3 at this time).

It seems that by the time ldbm_initialize is called, lbi->lbi_directory
should be set, but it isn't.  Actually, I don't even know why they
bother having an lbi_directory member there -- it makes no sense.  At
that point it is not yet time to deal with backend-specific
configurations, and none are available.  The easiest fix right now would
be to not set the home at all, although there are certainly advantages
in setting it.

If I gather correctly, ldbm_back_open is the function to initialize the
portion of the backend environment that will be shared by all instances
of a given type of backend (in this case back-ldbm).  For back-ldbm, it
allocates a  private structure, of type ldbm_backend_info, which has the
member lbi_directory.

Later, the function ldbm_back_db_open(BackendDB *be) has
li->li_directory available, and is initialized.  Thinking out loud
here.  I'm open to suggestions.