From: Jon Udell <udell@monad.net> Hi Leif, I've just been poking around in an Exchange Server with PerLDAP. Was puzzled to see that PrintLDIF was only reporting all lowercase attributes, not any mixed-case attributes. I haven't figured out why, but I did notice that although the top level of the $entry structure exhibited this pathology, its internal _self_obj_ looked OK. So I changed to grep((print "$attr: $_\n"), @{$self->{_self_obj_}->{$attr}}); from grep((print "$attr: $_\n"), @{$self->{$attr}}); in ::Entry::PrintLDIF. Which seems to work, but I know there's got to be more to the story. I'm attaching a Data::Dumper dump of $entry following a search. As you can see, all non-lowercase attributes at the root level of $entry are undef. I've only just noticed this because, working with Netscape Directory Server, I think I've only been seeing lowercase attributes. Exchange uses mixed-case attributes. I can't find the place in your Perl code where this is happening, but it's got to be there. Because in Conn::nextEntry, I can do @vals = ldap_get_values_len($self->{"ld"}, $self->{"ldentry"}, $attr); print "$attr: $vals[0]\n"; and see all the attributes. So they're coming back OK from the LDAP API level. I guess one set of attributes mirrors the other, for change-tracking purposes? I dunno, you sort of lost me with that multilevel blessed object sleight of hand.... This is, by the way, using the Win32 ActiveState PerlDAP module, if that matters (it shouldn't, I don't think). Regards, -- Jon Udell - http://udell.roninhouse.com/ $VAR1 = bless( { 'sn' => [ 'Udell' ], '_self_obj_' => bless( { 'title' => [ 'foo' ], 'mail' => [ 'judell@WALNUT.UdellInc..com' ], 'rfc822Mailbox' => [ 'judell@WALNUT.UdellInc..com' ], 'rdn' => [ 'judell' ], 'Hide-From-Address-Book' => [ 'FALSE' ], 'st' => [ 'NH' ], '_oc_order_' => [ 'objectClass', 'rdn', 'cn', 'distinguishedName', 'Hide-From-Address-Book', 'rfc822Mailbox', 'mail', 'textEncodedORaddress', 'otherMailbox', 'postalAddress', 'conferenceInformation', 'mailPreferenceOption', 'department', 'givenName', 'Home-MTA', 'l', 'physicalDeliveryOfficeName', 'postalCode', 'st', 'sn', 'telephoneNumber', 'title' ], 'l' => [ 'Keene' ], 'telephoneNumber' => [ '555-1212' ], 'objectClass' => [ 'organizationalPerson', 'person', 'Top' ], 'postalCode' => [ '03431' ], 'physicalDeliveryOfficeName' => [ 'home office' ], 'otherMailbox' => [ 'MS$UDELLINC/WALNUT/JUDELL', 'CCMAIL$Udell, Jon2 at WALNUT' ], 'cn' => [ 'Jon Udell' ], 'dn' => 'cn=judell,cn=Recipients,ou=WALNUT,o=Udell Inc.', 'department' => [ 'no dept.' ], 'distinguishedName' => [ 'cn=judell,cn=Recipients,ou=WALNUT,o=Udell Inc.' ], 'Home-MTA' => [ 'cn=Microsoft MTA,cn=INTERGRAPH,cn=Servers,cn=Configuration,ou=WALNUT,o=Udell Inc.' ], 'postalAddress' => [ '31 Walnut St' ], 'givenName' => [ 'Jon' ], 'mailPreferenceOption' => [ '0' ], 'conferenceInformation' => [ '/' ], 'textEncodedORaddress' => [ 'c=US;a= ;p=Udell Inc.;o=WALNUT;s=Udell2;g=Jon;' ] }, 'Mozilla::LDAP::Entry' ), 'sn' => $VAR1->{'sn'}, '_self_obj_' => $VAR1->{'_self_obj_'}, 'title' => $VAR1->{'_self_obj_'}{'title'}, 'mail' => $VAR1->{'_self_obj_'}{'mail'}, 'rfc822Mailbox' => undef, 'rdn' => $VAR1->{'_self_obj_'}{'rdn'}, 'Hide-From-Address-Book' => undef, 'st' => $VAR1->{'_self_obj_'}{'st'}, '_oc_order_' => $VAR1->{'_self_obj_'}{'_oc_order_'}, 'l' => $VAR1->{'_self_obj_'}{'l'}, 'telephoneNumber' => undef, 'objectClass' => undef, 'postalCode' => undef, 'physicalDeliveryOfficeName' => undef, 'otherMailbox' => undef, 'cn' => $VAR1->{'_self_obj_'}{'cn'}, 'dn' => 'cn=judell,cn=Recipients,ou=WALNUT,o=Udell Inc.', 'department' => $VAR1->{'_self_obj_'}{'department'}, 'distinguishedName' => undef, 'Home-MTA' => undef, 'postalAddress' => undef, 'givenName' => undef, 'mailPreferenceOption' => undef, 'conferenceInformation' => undef, 'textEncodedORaddress' => undef }, 'Mozilla::LDAP::Entry' );

More from Jon: That's good. I have no further info. Where it stands: I'm not sure which of the two attribute structures is canonical. I am pretty sure that arbitrarily switching from one to the other, to work around the problem I cited, can't be the right thing to do.

*** This bug has been marked as a duplicate of 2168 ***