[please keep replies on the list]
Allan E. Johannesen wrote:
"ando" == Pierangelo Masarati <ando@sys-net.it> writes:
Allan E. Johannesen wrote:
Hmmm. Looking at the code as I type this, perhaps the only evil one is the
one with colons and the "0x" hex field. If I change
entryCSN: 2002120818:17:53Z#0x0061#0#0000
ando> This really looks evil. I think that assert needs to be relaxed into a
ando> run-time error, but I don't really see how that data could have made it
ando> into your database. The old syntax should be allowed, as far as I can
ando> remember. In any case, slapadd should tell you exactly what entry
ando> couldn't be imported, you should be able to check what the offending
ando> entryCSN looks like.
I don't think it's "evil", but simply "old".
I think it's evil because I don't recall the CSN syntax ever being like
that.
I looked at what 2.4.6 does with "old", but "not THAT old", CSNs,
That's my point: "THAT old" should not be, that's the reason of that
assert: make sure only known formats get there during CSN handling
development. Of course, in production a run-time error would be better,
since one can never know how and why garbage gets there.
In any case, I believe rewriting those CSNs according to either old or
new format should solve your problem. Of course, if entryCSN's like
that surface again, there must be some piece of software that generates
them. In that case, further investigation will be required.