Re: Bug fix for slurpd - seconds going from 9 to 10 digits

[James Bourne <jbourne@MtRoyal.AB.CA>]

On Sun, 9 Sep 2001, Dale, Warren wrote:

> I think that there is a bug in slurpd due to the seconds since epoch going
> over from 999,999,999 to 1,000,000,000.
>

Find attached what might be a more elegant version of the same fix...

I would however like to know why it is that anyone would string value a
time_t, then compare it using strcmp?  This is a major inconvenience to many
people that use openldap daily in production environments such as ours.

This is against 2.0.11.  I don't currently have a copy of CVS and don't have
the time to get a copy to work with, as I am apply this patch to our
production server.

Regards
James Bourne


> It is late at night here so I (crudely) fixed version 1.2.9 like this:
>
> diff -c ri.c.19990810 ri.c
> *** ri.c.19990810       Tue Aug 10 11:03:50 1999
> --- ri.c        Sun Sep  9 22:35:28 2001
> ***************
> *** 237,242 ****
> --- 237,246 ----
>         ret = 1;
>       } else if ( x < 0 ) {
>         ret = 0;
> + #ifndef THEY_HAVE_FIXED_THE_SECONDS_ONE_TRILLIAN_PROBLEM
> +       if (atol(re->re_timestamp) > atol(ri->ri_stel->last))
> +           ret = 1;
> + #endif
>       } else {
>         /* timestamps were equal */
>         if ( re->re_seq > ri->ri_stel->seq ) {
>
> I check latter version, and they all seem to require a similar patch.
>
>
>
> Warren Dale -- WorldCom
> * Email .. dale.warren@wcom.com.au
> Phone
> * Voice .. (02) 9434-5354 : +61 2 9434 5354
> * Mobile . 0412-700-966 ::: +61 412 700 966
>

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

******************************************************************************
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
******************************************************************************

--- openldap-2.0.11/servers/slurpd/ri.c~	Tue Oct  3 11:22:49 2000
+++ openldap-2.0.11/servers/slurpd/ri.c	Sun Sep  9 20:00:16 2001
@@ -234,12 +234,14 @@
     Re	*re
 )
 {
-    int	x;
+    time_t	x;
     int	ret;
 
     /* Lock the St struct to avoid a race */
     sglob->st->st_lock( sglob->st );
-    x = strcmp( re->re_timestamp, ri->ri_stel->last );
+
+    x = atol(re->re_timestamp) - atol(ri->ri_stel->last);
+    
     if ( x > 0 ) {
 	/* re timestamp is newer */
 	ret = 1;