Re: (ITS#6553) Test043 oddities under Windows

[masarati@aero.polimi.it]

Isn't ldif-filter supposed to deal with this?  Probably, test043 needs to
sort entries (-s bdb=a,hdb=a).

p.

> 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!).
>
>
>
>