[Date Prev][Date Next]
Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
I had restarted the server many times and it still worked, so I don't
think the data was cached. Maybe the different method of access caused
the difference, because the non-corrupted entries were still accessible
via their id, so direct access worked.
Could it be that slapcat doesn't correctly handle the case of invalid
entries (entries with decoding errors)? Before this generic patch, I
checked if the current entry had the id of the first invalid entry and
in this case I incremented the ID by three, got the resulting entry and
continued the export --> slapcat "skipped" the entries which it couldn't
decode and then continued processing normally.
Sorry that I can't test catastrophic recovery any more, because I have
deleted the corrupted database, but I think that the main problem was
that slapcat (and also other ldap-tools) wasn't able to decode the few
damaged entries and didn't try to work around that problem.