Re: (ITS#4650) ldapmodrdn vs ldapmodify

[Kurt@OpenLDAP.org]

I see no indication that any of the behavior you are seeing
is due to software bug.  It appears this report is primarily
a software use issue.  As addressing such issues is beyond
the scope of this system, I intend to close this report.

- Kurt

At 09:44 AM 8/25/2006, ccontavalli@commedia.it wrote:
>Full_Name: Carlo Contavalli
>Version: 2.3.x
>OS: Debian GNU/Linux
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (81.208.74.182)
>
>
>Ok, if I run something like 
>======
>$ ldapmodrdn -x
>force=FALSE,cn=J9v5sLCeU0zyJ,dc=test,dc=it
>enable=TRUE
>======
>the change is performed, the dn of the entry is changed (assuming the object
>contains both the attribute force and enable and the schema is ok...).
>If the same operation is performed using ldapmodify moddn, with something like:
>======
>$ ldapmodify -x
>dn: force=FALSE,cn=J9v5sLCeU0zyJ,dc=test,dc=it
>changetype: moddn
>newrdn: enable=TRUE
>deleteoldrdn: 1
>======
>the operation fails with the error:
>======
>modifying rdn of entry "force=FALSE,cn=J9v5sLCeU0zyJ,dc=test,dc=it"
>modrdn completed
>ldap_rename: Object class violation (65)
>        additional info: object class 'mailModuleStatus' requires attribute
>'force'
>======
>if ldapmodify does not change the attribute of the dn, like with:
>======
>dn: force=FALSE,cn=J9v5sLCeU0zyJ,dc=test,dc=it
>changetype: moddn
>newrdn: enable=TRUE
>deleteoldrdn: 1
>======
>everything works ok.
>
>Cheers, 
>Carlo