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

["Dale, Warren" <Dale.Warren@wcom.com.au>]

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.

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