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

[masarati@aero.polimi.it]

> Full_Name: Himmelbauer
> Version: 2.4.19
> OS: Gentoo Linux
> URL: ftp://ftp.openldap.org/incoming/himmelbauer-100301.patch
> Submission from: (NULL) (92.248.100.200)
>
>
> Was not able to retrieve database entries from a corrupted LDAP database
> using
> slapcat (openldap 2.4.19) with option -c. It aborts after the first
> corrupted
> entry with
>
> <= entry_decode: slap_str2undef_ad(object&#65533;
!p):
> AttributeDescription
> contains inappropriate characters
> # no data for entry id=xxxxxxxx
>
> and doesn't continue with the next valid entry as I would have expected.
>
> A damaged database is not good, but as slapcat is described as the tool to
> recover the non-corrupted data in various forums, it would be good when it
> really continues on errors. Other ldap-related tools like ldapsearch
> ignore the
> damaged data, so it is really annoying, when you want to recover your data
> and
> don't even get all the readable entries.
>
> The patch corrects the handling of damaged entries by slapcat when -c is
> used,
> so that the output is continued with the next non-damaged entry. When -c
> is not
> used slapcat stops after the first corrupted entry (as expected).
>
> The patch works for me, but I know that it is not really correct, because
> when
> there would be no non-damaged entry left it would either cause a endless
> loop or
> some crashes.
>
> So a modification would be needed to stop the loop when the last database
> entry
> was processed, but I didn't know how to access that id.

I do not quite understand this report and your fix.  The code seems to
work as intended.  "continue" here means keep processing the database if
an entry can't be extracted from the database.  This does by no means
imply that processing can always continue.  If the database is corrupted,
it is likely that from the first appearance of the corruption, not even
the next entry id can be retrieved at all.  Otherwise, if the only error
consists in not being able to extract an entry, continuation occurs as
expected in the current code.

What likely happened in your case was that as soon as the database
corruption was encountered, be_entry_next() was unable to compute the id
of the next entry.  This is why you don't even get a log of the ids of the
entries that couldn't be extracted.

I'd close this ITS.

p.