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

[sysadmin@htl-leonding.ac.at]

Maybe I haven't described the situation correctly:
The database was used for managing user accounts (via nss_ldap). The 
database seems to had three corrupted entries in the middle (good 
entries were following after that). The command "getent passwd" i.e. 
still listed all users except those three with corrupted entries, but 
export via slapcat and reimport of the data would have led to loss of 
many more accounts. Lossing half your data is not the expected behaviour 
for a tool, which should list all the existing (or at least somehow 
readable) database entries.

The important point is that slapcat cancelled the export at the first 
corrupted database entry and didn't even try to get to the non-corrupted 
database entries (which were seen by the other LDAP-tools). It didn't 
even try in "continuation" mode, so there was no way to rescue all the 
readable data via slapcat. For slapcat all entries occuring after the 
first corrupt entry were lost. As the remaining good entries were still 
accessible and visible via the other tools communicating with slapd via 
the port 389, the expected behaviour for slapcat would have been to try 
harder to ignore the damaged entries and to recover the remaining 
readable entries after them. Maybe slapcat really failed to extract the 
next entries id, but in "continuation"-mode it should try hard to 
workaround any errors caused by non-readable entries. In case of an 
non-readable entry my patch continues stupidly incrementing the id by 1 
and trying to read that entry. As soon as it can extract an entry, it 
continues processing.