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