COMMAND
Y2K
SYSTEMS AFFECTED
Win NT (post SP4)
PROBLEM
Ilya Slavin found following. 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, Ilya 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 Ilya 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.
These results were confirmed by Russ Cooper (the moderator
NTBugTraq 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. 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").
SOLUTION
There's number fot this bug and that's all.