On May 23, 2010, at 9:57 AM, [email protected] 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
