On modifyRdn server now adds additional Rdn attribute

• Key: DIRSERVER-306
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Blocker
• Assignee: Alex Karasulu
• Reporter: Alex Karasulu

Description

I changed the name of an entry like ou=Users, dc=example, dc=com to ou=users, dc=example, dc=com which had a single ou=Users. I expected this operation to delete the old attribute rather then just add the new one. This can become a serious issue hence the reason why its a blocker.

Comments

[Stefan Zoerner]

I think it depends on the modify DN operations parameters whether the old RDN value is kept or not.
Example:

--8<--

# create an entry for a person
#
dn: cn=Myra Ellen Amos,ou=system
changetype: add
objectclass: top
objectclass: person
cn: Myra Ellen Amos
sn: Amos
description: an American singer-songwriter

# Change RDN
# old RDN value of cn should continue to be in place
#
dn: cn=Myra Ellen Amos,ou=system
changetype: modrdn
newrdn: cn=Tori Amos
deleteoldrdn: 1

-->8--

The deleteoldrdn may be 0 or 1. 0 keeps the old RDN value, 1 deletes it.
When I apply the above LDIF to a 0.9.1 ApacheDS,

$ ldapmodify -p 10389 -D uid=admin,ou=system -w ***** -f modRdn.ldif
adding new entry cn=Myra Ellen Amos,ou=system
moving cn=Myra Ellen Amos,ou=system to cn=Tori Amos

And the entry of Tori looks like:

dn: cn=Tori Amos,ou=system
sn: Amos
objectclass: person
objectclass: top
cn: Tori Amos
description: an American singer-songwriter

The test with deleteoldrdn=0 works as well.

[Trustin Lee]

Stefan,

What happens if user first modifies RDN without deleting old RDN and then modifies RDN again with deleveoldrdn=1?
Should LDAP server delete all RDNs which were not deleted by the first operation in the second operation? What if the new RDN of the second operation was not 'cn' but 'ou' or 'dc'?

[Trustin Lee]

Alex, I tested modifyRN operation with JXplorer, but it looks like it is working OK. Am I getting something wrong?

[Stefan Zoerner]

I have attached an LDIF example for the first case.

I applied it to a test server (IBM Tivoli Directory Server) and the result (after both modrdn) is:

dn: cn=Myra E. Amos,dc=example,dc=com
objectclass: top
objectclass: person
cn: Myra Ellen Amos
cn: Myra E. Amos
sn: Amos
description: an American singer-songwriter

I think behaviour is logical. The first modrdn adds a value to cn and does not delete the old value of the cn.
Therefore, Tori has two values for attribute cn after the first modrdn, one of them forms the rdn "cn=Tori Amos", the other "cn=Myra Ellen Amos" does not (cn allows multiple values).

The second operation adds a new value for cn ("cn=Myra E. Amos"), uses it as the new rdn, and deletes the attribute value of the old rdn ("cn=Tori Amos").
As a consequence, the attribute value "cn=Tori Amos" is gone, but "cn=Myra Ellen Amos", which was not part of the rdn not.

The point here is that cn allows multiple values. Behavior is different otherwise.

[Alex Karasulu]

Let me see if I can whip together a test case to flush out the bug. Also I have to take a look at and process Stefan's comments here. Thanks!

[Stefan Zoerner]

I already have a JNDI test case for the LDIF file above.
Let me check the behaviour against at least two other LDAP servers, then I will file it as an attachment.

[Stefan Zoerner]

Here it is. Not a complete coverage of the mod rdn (still some situations left), but as least the ops of the LDIF are included in the test methods.
I run the JNDI code successfully against OpenLDAP 2.1 and Tivoli DS 5.2. Therefor I am quite sure that the behaviour as describeb with the tests is valid.
In my current build of Apache DS, two of the three methods fail (those who keep the rdn).

[Alex Karasulu]

Looks like your test case is passing here Stefan. This issue appears to be fixed. Thoughts? Trustin, Stefan shall I close this issue?

[Alex Karasulu]

Committed the test cases here on revision 239709:


http://svn.apache.org/viewcvs.cgi?rev=239709&view=rev

[Alex Karasulu]

I'll close this for now but we can reopen it if Trustin you or Stefan still have issues with it.

[Stefan Zoerner]

I have still a case were it does not work. Unfortunately it is not possible to add the JUnit test to this issue. I guess we have to reopen it first.

Anyway: Basic idea is to have an entry like this:

dn: cn=Tori Amos,ou=system
sn: Amos
cn: Tori Amos
objectclass: person
objectclass: top

Then change the RDN to "sn=Amos" and keep the old one. The result with current ApacheDS is an entry which looks like this:

dn: sn=Amos,ou=system
sn: Amos
sn: Amos
objectClass: person
objectClass: top
cn: Tori Amos

Expected result is that "sn=Amos" does occur once in the entry, not twice.
If someone reopens the issue, I will attach my JUnit test case on this.

[Alex Karasulu]

Reopening issue thanks to Stefan catching the bug. Hopefully his test case addition will help us nail this one down.

[Alex Karasulu]

Stefan I added your test case to the svn repo so all you might want to do is attach a patch for it in this existing test case rather than attaching a new test case all together. Thanks Stefan!

[Stefan Zoerner]

Here is a patch for the JUnit test. It includes a new method which still fails with the current Apache DS (change rdn from cn=... to sn=... as described above). This time I resisted to use the cute little patch button in Eclipse and created the file with "svn diff". Therefor I hope the integration should not cause any trouble this time.

[Alex Karasulu]

Stefan you must have not updated the svn working directory before you generated the patch. All patch chunks seemed to have failed. Please svn up the repo and regenerate the patch. Sorry about having you do this again but looks like I cannot manualy patch the file without screwing something up.

Thanks!

[Alex Karasulu]

Commited fix changes in revision 264048 here along with Stefan's test case patch:

http://svn.apache.org/viewcvs.cgi?view=rev&rev=264048

Looks like a small fix for a big problem.