Leif, Below are the pm's that have good cert behavior and bad ( top) behavior. I fetched them from the CVS today, but they are certainly the same ones I was talking about in my original message. I had fetched them around 02:30 Sunday. I have some other stuff to work on, and I guess I can stall on the question of whether I can copy certificates. I would rather just give a positive answer when it all works. I will be focusing on NT from here on. I don't know if it matters which NT or SDK I'm using. I'm running NT4 sp4, the domestic 3.1 SDK, ActivePerl build 509, DS311, and ES 3.6. Do you have an idea what part of the code this problem is coming from? I would like to, at least attempt to, read through the code and see if I can make heads or tails of it. Steve $Id: API.pm,v 1.13.2.4 1999/03/23 21:41:58 leif%netscape.com Exp $ $Id: Conn.pm,v 1.19.2.4 1999/03/23 21:41:58 leif%netscape.com Exp $ $Id: Entry.pm,v 1.10.2.6 1999/03/26 09:42:31 leif%netscape.com Exp $ $Id: LDIF.pm,v 1.6.2.8 1999/04/01 19:36:23 kristian%netscape.com Exp $ $Id: Utils.pm,v 1.11.2.3 1999/03/23 21:41:59 leif%netscape.com Exp $ Leif Hedstrom wrote: > "Steven T. Hatton" wrote: > > > I then downloaded from the 1_3 tree. That seems to work ok for 64-bit > > encoding of certificates, but (top) is now ( top). > > Is that the 1.3 from the CVS server, or from the FTP site? The CVS server > has new code checked in, but I haven't created a snapshot for the for that > yet (the FTP server has v1.3.1). I remember having this ( top) problem as > well, but can not reproduce it anymore. > > Let me know what versions you are using (e.g. send me the header IDs). I > can also send you a patch to go from v1.3.1 to the current CVS state if you > like. I'm working on a v1.3.2 snapshot, but would like to finish a couple > of more things before I do. > > -- leif

The code that was producing this bug was: { # Print the entry, grab another and print till done. while ($entry) { print h2("Here's an entry: "); $entry->printLDIF(); $outConn->add($entry); $entry = $inConn->nextEntry(); } }; The cause was the $entry->printLDIF(), which was modifying $entry. This bug was fixed between revision 1.6.2.9 and 1.6.2.10 of LDIF.pm, by kristian@netscape.com. The function pack_LDIF() was modifying values in the records passed through, (by modifying $val). The comment in Entry.pm getLDIFrecords() mentions the fact that it is returning a reference to the same values back, which is dangerous. I confirmed that using LDIF.pm revision 1.6.2.9 exhibited the behaviour of this bug, but revision 1.6.2.10 works fine. Steve Hatton also confirmed to me that the bug doesn't exist anymore: > Kevin, > > Thanks very much for the follow up. It seems to be fixed now. I haven't > been messing with it for a long time because I just didn't have time. I > hope it is a thing of the past. If I can reproduce it I will let you > know. I am now using the 1_9 branch. I just compiled it. The problem was > on NT. To tell the truth I don't remember if and when it happened on > Linux, but I believe at one point it did. Oh well, I'm glad I now have > this working. Perhaps I can go back to playing with perl. > > Steve