Le 13 févr. 2015 à 11:13, Howard Chu <hyc@symas.com> a écrit :
This has nothing to do with OpenLDAP. You're talking about Apple's privately hacked version of the code. Whatever they do in their custom attributes with their custom plugins is anybody's guess, but don't expect any Standards documented behavior to cover it.

I was hoping to not see an answer like that. So common in all Open Source communities.
You seems really fast to conclude that’s a problem of an hypothetic Apple hack. The source code used by Apple is available here http://opensource.apple.com/source/OpenLDAP/OpenLDAP-491.1/
Do you see a difference with the official repository who can lead to this problem?
I’m not asking for a « go to hell, it’s an Apple hack » answer.
If I’m asking here, it’s because I’m looking for a real valuable answer. Like for example what kind of mechanism in OpenLDAP source code can lead to this situation. An index or something like that for example.
Maybe it’s linked to an Apple hack, maybe not. In any case the only valuable answer for my question is a troubleshooting procedure for this kind of behavior. Nothing else.

The reason you so often see an answer like this is because people like
you want Open Source developers to do work for you for free...

The answer is as Howard said, Apple has modified the code, so pay for a
support contract with them and ask them. Or see if they will work for
you for free.

Our company has been using OpenLDAP for almost 15 years with billions of
transactions and have found the query results to always be utterly
deterministic...ie, we have always gotten out exactly what we put in and
asked for. Out inconsistencies have always been traced back to either
our inconsistent input or queries.

In your particular case, without working for you for free for several
hours to answer your question, it looks to me like you are adding an
additional query criteria that Apple's code is handling differently
based on the existence of the criteria.

For example, if I was querying an "unordered" hash data structure and
asking for any single element vs a specific element I would expect
similar behavior...with no criteria I get whichever element happens to
be first in the hash structure at that time and when I specify a hash
key I get the specific element data. But you would have to take the
time to research Apple's attribute & code to determine if that is a
valid analogy in this case.