[
https://issues.apache.org/jira/browse/DIRSERVER-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509182#comment-16509182
]
Emmanuel Lecharny commented on DIRSERVER-2235:
----------------------------------------------
FTR, we have unit tests that I have modified to cover your scenario :
{code:java}
@RunWith(FrameworkRunner.class)
@ApplyLdifs(
{
"dn: cn=modDn,ou=system",
"objectClass: person",
"cn: modDn",
"sn: snModDn",
"",
"dn: employeeNumber=test,ou=system",
"objectClass: person",
"objectClass: inetorgPerson",
"cn: modDn",
"employeeNumber: test",
"sn: snModDn",
"",
"dn: ou=container,ou=system",
"objectClass: organizationalUnit",
"ou: container"
})
@CreateLdapServer(transports =
{ @CreateTransport(protocol = "LDAP"), @CreateTransport(protocol = "LDAPS")
})
public class ClientModifyDnRequestTest extends AbstractLdapTestUnit
{
...
private static final String DN = "cn=modDn,ou=system";
private static final String DN_CONTAINER = "ou=container,ou=system";
...
@Test
public void testMoveAndRenameWithDeleteOldRdnShouldDeleteOldRdn() throws
Exception
{
Dn newDn = new Dn( "cn=modifiedDn", DN_CONTAINER );
connection.moveAndRename( new Dn( DN ), newDn, true );
assertTrue( connection.exists( newDn ) );
assertFalse( connection.exists( DN ) );
Entry entry = connection.lookup( newDn, "*", "+" );
assertTrue( entry.contains( "cn", "modifiedDn" ) );
assertFalse( entry.contains( "cn", "modDn" ) );
assertTrue( entry.containsAttribute( SchemaConstants.MODIFIERS_NAME_AT
) );
assertTrue( entry.containsAttribute(
SchemaConstants.MODIFY_TIMESTAMP_AT ) );
SearchRequest searchRequest = new SearchRequestImpl();
searchRequest.setBase( new Dn( "ou=system" ) );
searchRequest.setFilter( "(objectClass=*)" );
searchRequest.setScope( SearchScope.SUBTREE );
SearchCursor cursor = connection.search( searchRequest );
while ( cursor.next() )
{
System.out.println( cursor.get() );
}
cursor.close();
}
{code}
The output is :
{noformat}
Entry
dn[n]: ou=interceptors,ou=configuration,ou=system
objectClass: top
objectClass: organizationalUnit
ou: interceptors
Entry
dn[n]: cn=modifiedDn,ou=container,ou=system
objectclass: person
objectclass: top
cn: modifiedDn
sn: snModDn
Entry
dn[n]: ou=users,ou=system
objectClass: top
objectClass: organizationalUnit
ou: users
Entry
dn[n]: ou=groups,ou=system
objectClass: top
objectClass: organizationalUnit
ou: groups
Entry
dn[n]: ou=system
objectClass: top
objectClass: organizationalUnit
objectClass: extensibleObject
ou: system
Entry
dn[n]: uid=admin,ou=system
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: tlsKeyInfo
uid: admin
userPassword: 0x73 0x65 0x63 0x72 0x65 0x74
publicKey: 0x30 0x81 0x9F 0x30 0x0D 0x06 0x09 0x2A 0x86 0x48 0x86 0xF7 0x0D
0x01 0x01 0x01 ...
publicKeyFormat: X.509
userCertificate: 0x30 0x82 0x01 0xF8 0x30 0x82 0x01 0x61 0x02 0x06 0x01
0x63 0xF2 0x46 0xE3 0xB2 ...
privateKey: 0x30 0x82 0x02 0x76 0x02 0x01 0x00 0x30 0x0D 0x06 0x09 0x2A
0x86 0x48 0x86 0xF7 ...
keyAlgorithm: RSA
privateKeyFormat: PKCS#8
cn: system administrator
sn: administrator
displayName: Directory Superuser
Entry
dn[n]: ou=container,ou=system
objectclass: organizationalUnit
objectclass: top
ou: container
Entry
dn[n]: prefNodeName=sysPrefRoot,ou=system
objectClass: top
objectClass: organizationalUnit
objectClass: extensibleObject
prefNodeName: sysPrefRoot
Entry
dn[n]: cn=Administrators,ou=groups,ou=system
objectClass: top
objectClass: groupOfUniqueNames
uniqueMember: 0.9.2342.19200300.100.1.1= admin ,2.5.4.11= system
cn: Administrators
Entry
dn[n]: ou=configuration,ou=system
objectClass: top
objectClass: organizationalUnit
ou: configuration
Entry
dn[n]: ou=services,ou=configuration,ou=system
objectClass: top
objectClass: organizationalUnit
ou: services
Entry
dn[n]: ou=partitions,ou=configuration,ou=system
objectClass: top
objectClass: organizationalUnit
ou: partitions
Entry
dn[n]: employeeNumber=test,ou=system
objectclass: organizationalPerson
objectclass: person
objectclass: inetorgPerson
objectclass: top
cn: modDn
sn: snModDn
employeenumber: test
{noformat}
As you can see, the old entry has been properly moved and renamed, and it's not
anymore present in the LDAP server, either through an {{exists}} call or
through a {{search}} request.
I have one question : when you say 'the old entry is still returned in searches
but it cannot be read', what is the code you use to get the old entry and to
read it?
Otherwise, can you provide the server logs ?
Thanks !
> After renaming an entry in ApacheDS, the directory loses the new entry
> ----------------------------------------------------------------------
>
> Key: DIRSERVER-2235
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2235
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 2.0.0-M20, 2.0.0-M24
> Environment: Debian Linux, x64
> Reporter: Roland Szabó
> Priority: Major
> Attachments: tesztelek.ldif
>
>
> When I rename an entry in our directory, the old entry is still returned in
> searches but it cannot be read. The new entry exists, but only when referred
> directly by its DN. I have to restart the server to clean this mess up.
> I tried to use the rename operation in JNDI, then I switched to the ApacheDS
> LDAP-API, but both method results in the same problem. We use the CN
> attribute as the RDN, and after renaming, the CN attribute of the entry is
> all lowercase, however the DN maintains the correct casing. If I update the
> CN attribute to the correct case, I can use the rename operation on the entry
> 1 more time. If I also close the connection between rename operations, I can
> rename the same entry 1 more time, but then it fails again.
> I tried to upgrade from M20 to M24, but the problem is still there.
> I do not really understand the reason...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
