[Fedora-directory-commits] ldapserver/ldap/servers/slapd/back-ldbm import.c, 1.8, 1.9

[Richard Allen Megginson (rmeggins)]

Author: rmeggins

Update of /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv1730/ldapserver/ldap/servers/slapd/back-ldbm

Modified Files:
	import.c 
Log Message:
Resolves: bug 249366
Bug Description: rhds71 - search filters returns too many entries on interger attributes value greater than 231
Reviewed by: nhosoi (Thanks!)
Fix Description: The problem is that the current code uses atol() to convert the string value to an integer.  long is 4 bytes or 8 bytes depending on the underlying platform.  These binary values are stored in the index as 4 or 8 byte values.  Finally, the behavior of atol() is different on the platform in overflow cases.  Instead of dealing with binary values, we must store the values in string format, and perform string comparison, string normalization, and string key generation on INTEGER syntax values.  I added another syntax type to the list in syntax.h.  The code in string.c and value.c was mostly usable.  I had to add some code in value_normalize to handle cases like "    -00000001" -> "-1" to make it work like atol(), and I had to add some code to value_cmp to handle the sign (e.g. positive is always greater than negative, no other comparison is necessary) and magnitude (longer number is larger/smaller than shorter number, depending on sign).  Otherwise, strcmp() doe!
 s the right thing (e.g. "50" > "49", the same as int(50) > int(49)).  One problem I ran into was that the value_normalize code takes just a char *, rather than a berval* or a char * + size_t length.  To be efficient, this function should return the new length of the normalized string.  Fortunately, none of the existing code cares about the length, but I needed the length for magnitude comparison, so I just used strlen for those cases.  Which should be fine.  value_normalize always produces a correctly null terminated string.  I rewrote the value_cmp code to use a simple if rather than the switch statement.  This makes it much clearer - if syntax is case insensitive, use slapi_utf8casecmp - if case sensitive, use strcmp - otherwise, error.

I also found a problem with the ldif2db code, which I uncovered because I added my integer indexes online and did an online import.  The db2index code will correctly clear the INDEX_OFFLINE bit after the index is completed, but the ldif2db code will not.
Platforms tested: RHEL5 x86_64
Flag Day: Yes, if you are upgrading and you have integer valued indexes, you will have to remove them and recreate them.
Doc impact: We will have to document this in the release notes.



Index: import.c
===================================================================
RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm/import.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- import.c	10 Nov 2006 23:45:39 -0000	1.8
+++ import.c	19 Sep 2007 19:32:03 -0000	1.9
@@ -1054,6 +1054,20 @@
     }
 
     if (job->flags & FLAG_ONLINE) {
+        /* make sure the indexes are online as well */
+        /* richm 20070919 - if index entries are added online, they
+           are created and marked as INDEX_OFFLINE, in anticipation
+           of someone doing a db2index.  In this case, the db2index
+           code will correctly unset the INDEX_OFFLINE flag.
+           However, if import is used to create the indexes, the
+           INDEX_OFFLINE flag will not be cleared.  So, we do that
+           here
+        */
+        IndexInfo *index = job->index_list;
+        while (index != NULL) {
+            index->ai->ai_indexmask &= ~INDEX_OFFLINE;
+            index = index->next;
+        }
         /* start up the instance */
         ret = dblayer_instance_start(job->inst->inst_be, DBLAYER_NORMAL_MODE);
         if (ret != 0)