Date: Tue, 23 Mar 1999 18:31:34 -0500 From: Ilya Slavin To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: NT Y2K issue (post SP4) Those of you who are in the process of deploying SP4 or are planning to do so should be aware that a new Y2K problem was discovered in this service pack. Here's the scoop. In the course of Y2K testing of Windows NT server and workstation, I patched the OS and all applications to their vendor recommended Y2K levels (that included SP4 on both types of systems as well as other fixes on the workstation). The test itself was to set the clock 30 seconds prior to midnight on December 31, 1999 and initiate a large file copy (by right-clicking on the initial file in Explorer, selecting copy, and then paste in the destination folder). The object was to have the copy process complete in 2000. This way the new file creation date would be in one year, and the last access date will be in the next. What I discovered was very troubling. On several attempts to run the test, both NT Server and NT Workstation (on two different computers) failed to roll the clock into the next year (while succeeding on most other attempts). Instead they went from 11:59:59PM on December 31st, 1999 to 12:00:00PM of the same day, thus adding another 12 hours to it. The first time I saw this I thought I made a mistake and set the clock to AM instead of PM, but the file creation date showed that it was indeed set correctly. These results were confirmed by Russ Cooper (the moderator of this mailing list) with a few twists: sometimes the clock can go forward by 12 hours instead of back. Also, it appears that this problem does not happen when you use the copy command from the DOS shell. After Russ' notes were added to the case I opened earlier with Microsoft (although I myself wasn't able to persuade the vendor the problem actually existed), a bug number was assigned to this issue. However, as of the time of this writing, we remain in the dark as to how far Microsoft has gotten with the test. While this may not seem like a very big deal, this bug may be troubling. Depending on the system call that triggers this problem (there have to be over a good dozen different ones occurring in the process of a file copy), this may turn out to be a serious problem. Please keep in mind that Microsoft is claiming commitment to Service Pack 4's Y2K compliance (as well as Service Pack 3's compliance "with minor issues"). So if they do confirm that this is a problem, they will likely issue a hot fix to existing Service Packs. Thus it may not be necessary to halt all SP4 deployment and wait for the next Service Pack, but you may find it helpful to keep the information provided in this message in mind as you plan deployment. As more details emerge, we'll post them to this list, but for the time being, it does not appear that SP4 is entirely Y2K compliant as was originally stated. I would also like to hear from anyone who was able to reproduce this problem - the more reports there are, the greater the chance that Microsoft will address this issue in a timely fashion. Ilya Slavin System Administrator Tudor Investment Corporation -------------------------------------------------------------------------- Date: Tue, 23 Mar 1999 17:06:18 -0800 From: Jason Garms To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Y2K issue (post SP4) We still have not been able to reproduce this reported bug under numerous system configurations, either using information supplied by Ilya, or with additional information from Russ. We are continuing to evaluate this and trying different system configurations to try to reproduce it. Thanks to Russ for his time today working with us on this. We would welcome any additional information that can be supplied on how to reproduce this bug. Please direct this info to our y2k reporting alias: y2k@microsoft.com. Thanks, -jasong Jason Garms Windows NT Security Microsoft Corporation -----Original Message----- >From: Ilya Slavin [mailto:Ilya.Slavin@TUDOR.COM] Sent: Tuesday, March 23, 1999 3:32 PM To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: NT Y2K issue (post SP4) Those of you who are in the process of deploying SP4 or are planning to do so should be aware that a new Y2K problem was discovered in this service pack. [text deleted...] As more details emerge, we'll post them to this list, but for the time being, it does not appear that SP4 is entirely Y2K compliant as was originally stated. I would also like to hear from anyone who was able to reproduce this problem - the more reports there are, the greater the chance that Microsoft will address this issue in a timely fashion. Ilya Slavin System Administrator Tudor Investment Corporation