Subject: FW: Any possible year 2000 problems with wu-ftpd?

From: "Roger A. Hanke" <[email-masked]>
Date: Tue, 14 Oct 1997 13:48:24 -0400

The following mail message pointed out one place WUFTPD code
would need to be changed to be year 2000 compliant. I never saw any
further followup on this mail and of course my managers are all hot 
on this ;^>

So if the change described below was made, does anyone know 
which Beta release was changed to become completely year 2000 compliant?
	Thanx,
	Roger Hanke
----------
From: 	Mark Galbraith[SMTP:[email-masked]]
Sent: 	Thursday, March 27, 1997 1:09 PM
To: 	[email-masked]
Subject: 	Re: Any possible year 2000 problems with wu-ftpd?

>>>>> "Kent" == Kent Landfield <[email-masked]> writes:

Kent> #  
Kent> # The subject says it all...I can't think of anywhere that wu-ftpd makes
Kent> # assumptions about the year that could cause problems, but I thought I'd
Kent> # run it by everyone just in case I overlooked something.  

Kent> Andy,
Kent> 	When I saw this question I laughed. Then I started to think about it
Kent> and then I went and looked...

Kent> There are three places where 1900 is used explicitly.  Two times in 
Kent> extensions.c and once in ftpshut.c.

Kent> extensions.c:        tmbuf.tm_year -= 1900;
Kent> extensions.c:        tm.tm_year -= 1900;
Kent> ftpshut.c:            (tp->tm_year) + 1900,

Kent> ftpshut.c should not be a problem as long as the system time functions do
Kent> the right thing. The two references in extensions.c can be handled with an 
Kent> if statement checking the date > 2000.  Question is, are there non-obvious
Kent> gotchas ?  

This should not present a problem.  If you look at the manual page for
localtime, you will see that the tm_year entry is the number of years
since 1900.  This entity is an 'int'.  On 16-bit machines (are there any
of these left?), this means the largest number of years could be 32,767
((2^15)-1); plus the 1900, or 34,667.  On 32-bit machines, which most
everyone should be on by now, the number is large enough that no one
should worry about it.  For those that care the value is ((2^31)-1) or
2,147,483,647 (plus the 1900).

The code should work so long as they are not trying to stuff the result
into a two-digit output format.

The first occurance in extensions.c is in the code for processing
entries from Shutdown process.  This file (specified by ftpaccess)
contains the date/time of the shutdown in a specified format.  The
format specification doesn't say whether the year must be four digits,
but it does state it should be greater than 1970.  I take that to mean
it must be four digits.  The code is scanning this value into the
tm_year field, and then adjusting it by subtracting 1900.  For years
greater than 1999, the resulting value will be 100 or more, and that's
just fine.  NO PROBLEM HERE.

The second occurance is in a function called newer().  This function is
passed a number of parameters, the first of which is a date string.  The
first sub-field of that date string is the year, and it is specified as
a 4-digit year.  This value is likewise put in the tm_year field, and
then adjusted by subtracting 1900.  NO PROBLEM HERE.

The entry in ftpshut.c is where the shutdown message gets written when
an ftpshut command is issued.  The adjustment is computing the date to
be printed in the file, which is later read by the first occurance in
extensions.c above.  The value is taken from the tm_year field after the
current time is adjusted for the offset.  The number of years in that
field is adjusted by adding 1900.  If the year was 2000, then the value
in the field would be 100, and the result of the adjustment would be
2000.  NO PROBLEM HERE.

Disclaimer:  In the following section, I refer to line numbers in
files.  I'm still using WU-FTP version 2.4 here, so all line numbers are
relative to the 2.4 version.

There is one additional place where we need to be concerned in FTP.  At
line 1568 in ftpcmd.c, produced from line 701 in ftpcmd.y, we have a
reference to tm_year which assumes a 2-digit value.  In fact, it even
has the '19' (century part of the year) hardcoded.  The patch to fix
this is:

*** ftpcmd.y-	Thu Mar 27 17:01:24 1997
--- ftpcmd.y	Thu Mar 27 17:05:32 1997
***************
*** 713,720 ****
                      struct tm *gmtime();
                      t = gmtime(&stbuf.st_mtime);
                      reply(213,
!                         "19%02d%02d%02d%02d%02d%02d",
!                         t->tm_year, t->tm_mon+1, t->tm_mday,
                          t->tm_hour, t->tm_min, t->tm_sec);
                  }
                  free($4);
--- 713,720 ----
                      struct tm *gmtime();
                      t = gmtime(&stbuf.st_mtime);
                      reply(213,
!                         "%04d%02d%02d%02d%02d%02d",
!                         t->tm_year+1900, t->tm_mon+1, t->tm_mday,
                          t->tm_hour, t->tm_min, t->tm_sec);
                  }
                  free($4);

Kent> Mirroring might get interesting globally if the mirroring software people use 
Kent> does not realize '00' is not less than '99'.  Well, at least for a day or so 
Kent> until all the mirror sites redownload everything and resync their file 
Kent> timestamps... I think I'll be on vacation that week.  

Mirroring is another issue, and another program.  The people with access
to those programs should be checking them to see if they are affected by
year-2000 problems.

-- 
Mark Galbraith                   Member of The HTML Writers Guild
Engineer, Internet Services	              http://www.hwg.org/
Triad Systems Corporation
(PGP Fingerprint=1CB9 7481 AD5C 5709  690B AC09 7F65 D6F6)

---

From: Kent Landfield <[email-masked]>
Date: Tue, 14 Oct 1997 13:05:04 -0500 (CDT)

# 
# The following mail message pointed out one place WUFTPD code
# would need to be changed to be year 2000 compliant. I never saw any
# further followup on this mail and of course my managers are all hot 
# on this ;^>
# 
# So if the change described below was made, does anyone know 
# which Beta release was changed to become completely year 2000 compliant?
# 	Thanx,
# 	Roger Hanke

In the FIXES-2.4.2-BETA-14 file Stan writes:
-----------------------------------------------------------------------------
Mark Galbraith noted a Y2K compliance problem in ftpcmd.y where the year
would always be printed as 19XX. This is now fixed. Unfortunately, it appears
that noone opened a ticket on this one that I can find. This came from the
mailing list. I believe that wu-ftpd is as Y2K compliant as it can be with
this fix.
-----------------------------------------------------------------------------

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: [email-masked]             http://www.landfield.com/
Please send comp.sources.misc related mail to [email-masked].
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/