15.11.04 00:50:02, Martin Stjernholm wrote:
No. The FILETIME values in the WIN32_FIND_DATA structure are defined as the number of 100-nanosecond intervals since January 1, 1601 00:00 UTC on *all* Windows versions. Likewise, the behaviour of FileTimeToLocalFileTime, and the bug, is identical on NT and W9x.
Doesn't that contradict the comment in the CRT source? (Not that I necessarily believe that the comment must be correct.)
The comment is very old, and what it refers to, albeit in a quite obscure way, is that Win32s incorrectly implements FILETIME based on local times. However this has not been carried over to Win32c aka W9x, I have tested and confirmed that W9x implements FILETIME exactly like NT/2K/XP. So the comment is not relevant for Pike anymore, which would never run on Win32s anyway.
But if it isn't cheap to check the filesystem type, we probably can't afford to do it anyway.
Well, it's not THAT expensive:
GetVolumeInformation( "C:", NULL, 0, NULL, NULL, NULL, szFs, 8);
For the first parameter, the root directory must be extracted from the file name. If the file name doesn't contain a drive specification, that parameter should be chosen as NULL, then GetVolumeInformation uses the current drive.
Then, if "NTFS" or "HPFS" is returned in szFs, the Pike implementation low_stat (changed to use my proposed calculation) should be used, otherwise the standard _stat function.
Btw, speaking of DST bugs, it seems GetFileTime, which is used by Stdio.File.stat, has an even more nasty one:
FAT records times on disk in local time. GetFileTime retrieves cached UTC times from FAT. When it becomes daylight saving time, the time retrieved by GetFileTime will be off an hour, because the cache has not been updated. When you restart the machine, the cached time retrieved by GetFileTime will be correct.
Firstly, I don't see why it would get incorrect; it's afterall cached in UTC where there's no such thing as DST.
Indeed, it seems that Micro$oft is very, very confused by DST. By "incorrect" they probably mean "incorrect in comparison to our already incorrect implementation of FILETIME values in WIN32_FIND_DATA", and not "incorrect" in the absolute sense of the word :)
Regarding Stdio.File.stat, it should probably be changed to use my proposed combination of _stat/_low_stat as well - avoiding redundancy and more bugs. BTW, I just noticed the function "convert_filetime_to_time_t" in that context - which exactly implements my proposed calculation, albeit a little more expensive by using floats instead of INT64...
Axel