#48370 The 'eq' index does not get updated properly when deleting and re-adding attributes in the same ldapmodify operation
Closed: wontfix None Opened 5 years ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1282457

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:
Deleting an indexed multi value attribute and re-adding it with the same value
in the same ldapmodify operation does not update the 'pres' index properly.

Version-Release number of selected component (if applicable):
389-ds-base-1.2.11.15-65.el6_7.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Setup a RHDS server (stand-alone)
2. Create a user:
   # ldapadd -x -h localhost -D 'cn=Directory Manager' -w <password> <<-EOF
   dn: uid=user0099,ou=People,dc=example,dc=com
   givenName: Test
   sn: User
   loginShell: /bin/bash
   uidNumber: 10099
   gidNumber: 10099
   objectClass: top
   objectClass: person
   objectClass: organizationalPerson
   objectClass: inetorgperson
   objectClass: posixAccount
   uid: user0099
   gecos: Test User
   mail: user0099@dev.null
   mail: alias@dev.null
   cn: Test User
   homeDirectory: /home/user0099
   EOF

3. Update the mail attribute by deleting all values and add only one value,
   that was previously used, in the same ldapmodify command:
   # ldapmodify -x -h localhost -D 'cn=Directory Manager' -w <password> <<-EOF
   dn: uid=user0099,ou=People,dc=local,dc=redhat,dc=com
   changetype: modify
   delete: mail
   mail: user0099@dev.null
   mail: alias@dev.null
   -
   add: mail
   mail: user0099@dev.null
   EOF
   ;;

4. Search for entries that have 'mail=alias@dev.null' (i.e. the value that was
   deleted):
   # ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" mail=alias@dev.null cn

5. Check the entry as returned by 4:
   # ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" uid=user009 mail



Actual results:
The search in 4. returns the user009 object while the mail attribute for
'alias@dev.null' has been deleted:
# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" mail=alias@dev.null cn
dn: uid=user0099,ou=People,dc=local,dc=redhat,dc=com
cn: Test User

The search in 5. shows this object does not contain the deleted mail
attribute:
# ldapsearch -LLL -x -h localhost -D 'cn=Directory Manager' -w <password> -b
"dc=example,dc=com" uid=user009 mail
dn: uid=user0099,ou=People,dc=local,dc=redhat,dc=com
mail: user0099@dev.null



Expected results:
The search in 4. not to return the user009 object.


Additional info:
A dbscan of the mail index db shows both values (even after the db cache is
flushed):
# dbscan -f /var/lib/dirsrv/slapd-<instance>/db/userRoot/mail.db4 | grep ^=
=alias@dev.null
=user0099@dev.null

The 'sub' index as part of the mail index does seems to be updated properly.

Built and ran tests. Looks good to me.

d9f37f1..63b80b5 master -> master
commit 63b80b5
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Dec 7 16:45:06 2015 -0500

ed1ad6c..4a53592 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 4a53592

bbb2758..5cd8f73 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 5cd8f73

378de6a..8e49d6d 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 8e49d6d

e8803f5..c24ecab 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit c24ecabcfcb9016c4049fa8b0524108c704b640d

0e2a753..c7cf000 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit c7cf000

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.33

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1701

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

a year ago

Login to comment on this ticket.

Metadata