Re: (ITS#6553) Test043 oddities under Windows

[masarati@aero.polimi.it]

> 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=a,hdb=a).
>
> Yes, Thanks.
>
> Here is a patch:

Works for me, but I can't check using windows.  I'd commit it, pending
verification.

Thanks, p.

> Index: test043-delta-syncrepl
> ===================================================================
> 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=a,hdb=a < $MASTEROUT | grep -iv "^auditcontext:" >
>> $MASTERF
> LT
> 344c344
> < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT
> ---
>> $LDIFFILTER -s bdb=a,hdb=a < $SLAVEOUT | grep -iv "^auditcontext:" >
>> $SLAVEFLT
>
>
>>
>> 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!).
>>>
>>>
>>>
>>>
>>
>>
>
>
>