Issue 547 - bug in ldapmodify means replace,add keywords are added as schema items during modify
Summary: bug in ldapmodify means replace,add keywords are added as schema items during...
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-05-26 09:24 UTC by jswith@jswith.f9.co.uk
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description jswith@jswith.f9.co.uk 2000-05-26 09:24:51 UTC
Full_Name: J.P.Swithenbank
Version: openldap-stable-20000515
OS: Linux(kernel 2.2.14)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.126.143.2)


a minor bug...but here goes...

in the process of modifying a reccord using ldapmodify...
using ldif...
e.g.
---
dn: cn=aperson,o=anorg,c=any
replace: mail
mail: aperson@anorg.dom
---
this would replace the schema item mail...as intended...but also add the
schema item replace with the value mail...if it already exists...the item
replace would be replaced with the new value!

ok.
Comment 1 Kurt Zeilenga 2000-05-26 22:22:40 UTC
At 09:24 AM 5/26/00 GMT, jswith@jswith.f9.co.uk wrote:
>in the process of modifying a reccord using ldapmodify...
>using ldif...
>e.g.
>---
>dn: cn=aperson,o=anorg,c=any
>replace: mail
>mail: aperson@anorg.dom
>---
>this would replace the schema item mail...as intended...but also add the
>schema item replace with the value mail...if it already exists...the item
>replace would be replaced with the new value!

You failed to specify the changetype.  ldapmodify attempts
to guess in such cases, sometimes it guess wrong.

Try:

dn: cn=aperson,o=anorg,c=any
changetype: modify
replace: mail
mail: aperson@anorg.dom

Comment 2 Kurt Zeilenga 2000-06-02 18:41:01 UTC
changed notes
changed state Open to Closed
Comment 3 OpenLDAP project 2014-08-01 21:06:11 UTC
Assumed resolved by suggestion.