Re: (ITS#6553) Test043 oddities under Windows

[mhardin@symas.com]

On May 23, 2010, at 9:57 AM, masarati@aero.polimi.it wrote:

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

Yes, Thanks.

Here is a patch:

Index: test043-delta-syncrepl
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v
retrieving revision 1.1.1.5
diff -r1.1.1.5 test043-delta-syncrepl
342c342
< $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT
---
> $LDIFFILTER -s bdb=3Da,hdb=3Da < $MASTEROUT | grep -iv =
"^auditcontext:" > $MASTERF
LT
344c344
< $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT
---
> $LDIFFILTER -s bdb=3Da,hdb=3Da < $SLAVEOUT | grep -iv "^auditcontext:" =
> $SLAVEFLT


>=20
> p.
>=20
>> Full_Name: Matt Hardin
>> Version: 2.4.22
>> OS: Windows 7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (74.38.117.141)
>>=20
>>=20
>> test043 fails under Windows because the contextCSN attribute for the =
entry
>> dc=3Dexample,dc=3Dcom are returned in different places within the =
entry for
>> the
>> producer and consumer. To wit:
>>=20
>> server1.flt-
>>=20
>> dn: dc=3Dexample,dc=3Dcom
>> 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=3DManager,dc=3Dexample,dc=3Dcom
>> createTimestamp: 20100518161938Z
>> entryCSN: 20100518161938.140191Z#000000#000#000000
>> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom
>> modifyTimestamp: 20100518161938Z
>> entryDN: dc=3Dexample,dc=3Dcom
>> subschemaSubentry: cn=3DSubschema
>> contextCSN: 20100518162026.443250Z#000000#000#000000
>> hasSubordinates: TRUE
>>=20
>>=20
>>=20
>> server2.flt-
>>=20
>> dn: dc=3Dexample,dc=3Dcom
>> 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=3DManager,dc=3Dexample,dc=3Dcom
>> createTimestamp: 20100518161938Z
>> entryCSN: 20100518161938.140191Z#000000#000#000000
>> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom
>> modifyTimestamp: 20100518161938Z
>> contextCSN: 20100518162026.443250Z#000000#000#000000
>> entryDN: dc=3Dexample,dc=3Dcom
>> subschemaSubentry: cn=3DSubschema
>> hasSubordinates: TRUE
>>=20
>>=20
>> 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.
>>=20
>> 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!).
>>=20
>>=20
>>=20
>>=20
>=20
>=20