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

Re: NEXTID (again!)

At 01:24 PM 8/12/99 -0500, Randy Kunkee wrote:
>> At 12:45 PM 8/12/99 -0500, Randy Kunkee wrote:
>> >If I simply run ldif2id2entry, NEXTID gets set correctly.  But I just
>> >ran an ldif2ldbm -j 10 last night, and NEXTID ended up containing "1".
>> >If ldif2id2entry is not doing this, what is?
>> This can happen when ldif2id2entry fails to create the NEXTID
>> file (for whatever reason) and slapd creates it on startup.
>If one of these programs did this,
>and kept the file open, and then exited after ldif2id2entry (building dn
>indices, or cn, or whatever), and then flushed the "1" on top of the
>correct value, could this be the scenario?

ldif2id2children and ldif2index should not be called until after
ldif2id2entry successful completes.  ldif2id2children/ldif2index
would only create a NEXTID file is one didn't exist after ldif2id2entry
was completed (this should actually be detected and treated as an
fatal error).

(in fact, ldif2id2children and ldif2index should be rewritten to
use the id2entry database to build indices instead of ldif).

>If this is the case, then writing 1 into NEXTID if it does not exist is
>not really a valid thing to do.  They should simply set NEXTID = 1
>internally and not write the file.  Would there be a problem with this?

They should not have depend upon the NEXTID.  (The dependency
is in ALLID handling which could be shortcutted not to use the
real nextid).  However, this will require a bit of work to
clean up.