[389-devel] Please review (take 3): [Bug 612771] RHDS 8.1/389 v1.2.5 accepts 2 identical entries with different DN formats

[Noriko Hosoi]

https://bugzilla.redhat.com/show_bug.cgi?id=612771

https://bugzilla.redhat.com/attachment.cgi?id=432203&action=diff

https://bugzilla.redhat.com/attachment.cgi?id=432203&action=edit

(In reply to comment #7)

> >  (From update of attachment 431976 [details])
> >  An entry may already have an nsUniqueID attribute - in that case, we should use
> >  it.  I was hoping we could use an attribute already in the entry for the
> >  renaming - I guess when you're not using replication, the nsUniqueID is not
> >  generated?  If so, perhaps we could just use entryid instead of nsuniqueid?
>    
Thanks, Rich!  Fixed it.  I confirmed nsUniqueId is always assigned regardless
of the replication use.  Now, upgradednformat utility picks up UUID from the
entry and add nsuniqueid=<UUID>  to the DN if duplicated DN is found.  (The
upgrade fails if UUID is not found in the entry, which should not happen.)
Since it always uses the existing UUID, we don't have to reindex nsuniqueid.
Thus, I removed the following special treatment for nsuniqueid since it is not
needed any longer.

> >  Also, at
> >  https://bugzilla.redhat.com/attachment.cgi?id=431976&action=diff#a/ldap/servers/slapd/back-ldbm/import.c_sec1
> >  - nsuniqueid will never have a DN value?
>    
Thanks,
--noriko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6646 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100715/c9f2f87a/attachment.bin