I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2, for what it matters, and db-4.6.21, for what it matters), and it works fine if you explicitly ask for hasSubordinates, while this specific attr is not returned if you request '+'. The fact hasSubordinates does not appear means that the appropriate backend operational attrs hook was not called, or its value was ignored.
After a quick check, I figured out that bdb_hasSubordinates is passed a copy of the original entry, thus without bdb information, and bdb_hasSubordinates bails out. Apparently, syncprov copies the entry instead of putting operational attrs in rs_operational_attrs in SlapReply. p. > Full_Name: Matt Hardin > Version: 2.4.22 > OS: Red Hat AS 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.117.141) > > > In test043 the test database defines a root entry of dc=example,dc=com. > For this > entry, the results of the ldapsearch do not include the hasSubordinates > attribute at all, in spite of the fact that the entry does have > subordinates. > Test043 passes, due to the fact that this attribute is missing from the > root > entry in both the provider and the consumer. > > Other entries with subordinates do include this attribute and its value is > correct in all the cases I examined. > > Here is the snippet from tests/testrun/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: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100512194705Z > entryCSN: 20100512194705.076849Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100512194705Z > contextCSN: 20100512194748.621773Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > > The version of BDB in use here is 4.8.30, although I note this happens > with > earlier releases of BDB as well. > > Also of interest is the fact that this test fails on some platforms (e.g. > Windows), because the provider slapd correctly reports > hasSubordinates=TRUE, > while the consumer omits the attribute entirely, in spite of the fact that > subordinate entries do exist on the consumer. > > -Matt > > >
