Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry

[sysadmin@htl-leonding.ac.at]

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.