(ITS#6553) Test043 oddities under Windows

[mhardin@symas.com]

Full_Name: Matt Hardin
Version: 2.4.22
OS: Windows 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.38.117.141)


test043 fails under Windows because the contextCSN attribute for the entry
dc=example,dc=com are returned in different places within the entry for the
producer and consumer. To wit:

server1.flt-

dn: dc=example,dc=com
dc: example
objectClass: organization
objectClass: domainRelatedObject
objectClass: dcObject
l: Anytown, Michigan
st: Michigan
o: Example, Inc.
o: EX
o: Ex.
description: The Example, Inc. at Anytown
postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
telephoneNumber: +1 313 555 1817
associatedDomain: example.com
structuralObjectClass: organization
entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643
creatorsName: cn=Manager,dc=example,dc=com
createTimestamp: 20100518161938Z
entryCSN: 20100518161938.140191Z#000000#000#000000
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20100518161938Z
entryDN: dc=example,dc=com
subschemaSubentry: cn=Subschema
contextCSN: 20100518162026.443250Z#000000#000#000000
hasSubordinates: TRUE



server2.flt-

dn: dc=example,dc=com
dc: example
objectClass: organization
objectClass: domainRelatedObject
objectClass: dcObject
l: Anytown, Michigan
st: Michigan
o: Example, Inc.
o: EX
o: Ex.
description: The Example, Inc. at Anytown
postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
telephoneNumber: +1 313 555 1817
associatedDomain: example.com
structuralObjectClass: organization
entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643
creatorsName: cn=Manager,dc=example,dc=com
createTimestamp: 20100518161938Z
entryCSN: 20100518161938.140191Z#000000#000#000000
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20100518161938Z
contextCSN: 20100518162026.443250Z#000000#000#000000
entryDN: dc=example,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE


While this is not a problem in operation, and is not specifically a bug
according to the RFCs, test043 nonetheless fails because it expects an exact
match in the ordering between the producer and consumer. It's not clear whether
the desired fix is in slapd or in the test itself.

This test does not fail on any other platforms with which we are currently
working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to
ITS#6549, which is now fixed (thanks Ando!).