Re: More on ldbm_initialize in libraries/libldbm/ldbm.c

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I added the backend "directory" directive to easily set a db
home for the (shared) db environment.  Namely, I got annoyed
at the __db... files getting created in the current working
directory.  As you noted, the current approach doesn't work
as intended.  It either should be fixed or removed.  I was
planning on removing it... but am open to suggestions (or
running code).

Kurt

At 03:43 PM 6/20/2001, Randy Kunkee wrote:
>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.
>
>Randy