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

RE: Corrupt index files

Good day,

Thanks again for your continual help with this.  It is very, very much

> I got some results like this (not sure if objectClass was the search
> criterion) using the ldbm backend with GDBM.
>  I think one record was
> being returned four times.

I haven't ever myself, but one of my co-workers recalls this happening with
the same version.  He said he did a re-index to fix it.

> Since updating to BDB (still 
> using the ldbm
> backend) I have not seen this.  FWIW I have
> index	objectclass	pres,eq
> I don't know whether that will help you.
> It looks a bit like the bdb backend is doing an indexed 
> search followed
> by a non-indexed search.

Could be.  Some output mangling reveals that no record is returned _more_
than twice.

> Do you get these problems if you 
> use the ldbm
> backend in 2.0.25 with BDB?

Yes.  I got exactly the same results with 2.0.21, 2.0.23 and 2.0.25 (yes, I
have been trying very, very hard to get something working).

I get the error as soon as I recreate the database with slapadd and my ldif.
If I delete the DB files and import again, I get duplicates on exactly the
same entries (I thought it would have been more random).  If I delete the
objectlclass index file and remake it with slapindex, that fixes the problem
but I have problems with other indexes (which I suppose I could try to
remake as well, but I felt I was beating a dead horse).

> The ldbm giant update lock was 
> implemented
> in 2.0.22 or so, so it shouldn't have problems with multiple-writer
> corruption.

I haven't even done an ldapmodify to the directory, so I don't think that
this would apply.

Is it possible the problem is something specific to slapadd?  Does it create
the index files any differently than slapindex?

Anything else I could possibly try?  Do I have a hope with 2.0.25 and gdbm?

Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948