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

ldif with too many newlines


I didn't see this in the ITS, nor did I come across any reference to this
on relevant mailing lists so I figure I'll post here.  Even if it turns   
out not
to be a bug perhaps this will help out anyone else with a similar
problem (but seeing that no one  else has mentioned this perhaps I
am the only one!).

I recently noticed a strange problem with searching.  I could not
search for a dn directly.  I had to use a wildcard.   So if I wanted
to search for "pmpin=11223344" (where pmpin was indexed) I would have
to do a search for "pmpin=11223344\*".

I now know what caused this.  At some point in my 16M ldif I had
two newlines (instead of one) seperating entries.  Example:

dn: pmpin=1560661,o=company.com
objectclass: top
objectclass: companypins
pmpin: 1560661
pmtype: 1.0
pmlen: 300

dn: pmpin=8886530670,o=company.com
objectclass: top
objectclass: companypins
pmpin: 8886530670
pmtype: 1.+
pmlen: 500

With this example (if I ran ldif2ldbm, and then started the server) I   
be able to find "pmpin=1560661", but searching for "pmpin=8886530670"
would turn up nothing unless I used "pmpin=8886530670\*".   However,
using wildcards tends to be quite a bit slower.

So, anything below the two new-lines would not be found with a
normal search.  I didn't try more than two lines seperating entries.

I was using ldif(5) as an example of how to make an ldif.  It says
at one point:

    Multiple entries within the same LDIF file are separated by blank   

Unless I am reading this wrong this implies that more than one blank
line can be between two entries.

It took me quite some time to figure out exactly why searching was
being so stubborn. =)

The backend I'm using is gdbm.  I'm on OSF1.  I'll gladly supply
any other information if requested.

I hope this helps somewhat.