Last mod time from stat() can be wrong on Windows NT/2000/XP #6080
Comments
From @steve-m-hayThis is a bug report for perl from Steve.Hay@uk.radan.com, When running on Windows NT/2000/XP Perl's built-in stat() function can The value returned should be expressed as seconds since the Epoch, and However, for a file created during a period when DST is in effect the Example: Running on Windows XP Professional, Service Pack 1 Open the "Date and Time Properties" applet from Control Panel Go to the "Time Zone" tab Select "(GMT) Greenwich Mean Time: Dublin, Edinburgh, Lisbon, London" Go to the "Date & Time" tab Enter the values "1 June 2002" and "14:00:00" (when DST is in effect) Click "OK" to save these settings and dismiss the applet Open a Comment Prompt and type the following commands: cd \Temp Now bring the "Date and Time Properties" applet back up, change the Type the following command in the Command Prompt: perl -e "print +(stat 'test.txt')[9]" This outputs a number like: 1022932805 depending on how soon you created the file 'test.txt' with the "echo" Finally, bring the "Date and Time Properties" applet back up, Repeat the above "perl" command in the Command Prompt, and a different 1022936405 The two values are different by 3600 seconds, i.e. the amount that a DST I believe that this output is wrong. The value returned by stat() should One final note: stat() behaves as I would expect, i.e. always returning Flags: Site configuration information for perl v5.8.0: Configured by radan at Thu Sep 5 09:10:23 2002. Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Locally applied patches: @INC for perl v5.8.0: Environment for perl v5.8.0: |
From @steve-m-hayMy original bugreport specified category=core but the RT system seems to have logged it as category=unknown instead. Is this a bug in perlbug? |
From @eserteMaybe some Windows expert may take a look at http://www.codeproject.com/datetime/dstbugs.asp and implement a fix based on the suggestions on this side. Otherwise Regards, |
From @steve-m-hayRegarding the above bug report: Is this something that is likely to be fixed in the Perl core any time soon? Slaven Rezic found a website with an excellent description of the I would love to see this done in the Perl core, but I'd be way out of my I could, however, produce a Win32::* module based on it quite easily. Any comments? Steve |
From @nwc10On Mon, May 19, 2003 at 04:44:20PM +0100, Steve Hay wrote:
Not obviously. People who understand the core usually already have too
I don't use Win32, so I have no direct concern about how this is fix. I think that the best thing to do is to write a module to implement the From an open-source cat herding perspective, if you're able to contribute Nicholas Clark |
From @steve-m-hayNicholas Clark wrote:
OK, I'll start putting together a Perl module. Does anyone have any thoughts on a suitable name for it? How about I was thinking of having the module provide overrides for the built-in # Override stat() and lstat() globally: # Override stat() locally; don't override lstat(). Why would anyone want to override stat() but not lstat()? Maybe: # Override stat() and lstat() locally: makes more sense. Any thoughts on these ideas, or any other ideas? Steve |
From @rgsSteve Hay <steve.hay@uk.radan.com> wrote:
As a general rule, I don't think that's a sensible default. |
From @steve-m-hayThe uploaded file Win32-UTCFileTime-1.00.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SH/SHAY/Win32-UTCFileTime-1.00.tar.gz This module addresses this bug report. It provides replacement stat(), lstat() and utime() functions that Hopefully the workaround in this module will be incorporated into the Steve |
From @smpetersOn Thu Jun 05 02:10:02 2003, shay wrote:
Steve, Do you know if there has been a fix in the MS core libraries since this Steve Peters |
From @steve-m-haySteve Peters via RT wrote:
I have a perl built with VC++ 2005 (VC8) and it still exhibits the same That's what I'd expect, really. When I created the Win32-UTCFileTime |
From @nwc10On Fri, Nov 16, 2007 at 02:52:25PM -0000, Steve Hay wrote:
Sigh. There are various things I could write about Microsoft for this one, DST is a whim of politicians. That should be a good enough reason to avoid it. And then timezones themselves. If I have a laptop, and it goes on a trip Nicholas Clark PS Should Perl 6 declare sanity on this from release 6.0.0 ? |
|
@dcollinsn - Status changed from 'open' to 'stalled' |
As discussed on the mailing list here: https://www.nntp.perl.org/group/perl.perl5.porters/2020/10/msg258453.html This just removes the declaration that we support the very old versions of Windows that have long since been EOLed. For reference of problems related to maintaining the EOLed versions: Perl#4145 Perl#6080 Perl#7410 Perl#8502 Perl#9025 Perl#12431 Perl#14687
This fixes at least two problems: - unlike UCRT, the MSVCRT used for gcc builds has a bug converting a FILETIME in an unlike current DST state, returning a time offset by an hour. Fixes GH #6080 - the MSVCRT apparently uses FindFirstFile() to fetch file information, but this doesn't follow symlinks(), so stat() ends up returning information about the symlink(), not the underlying file. This isn't an issue with the UCRT which opens the file as this implementation does. Currently this code calculates the time_t for st_*time, and the other way for utime() using a simple multiplication and offset between time_t and FILETIME values, but this may be incorrect if leap seconds are enabled. This code also requires Vista or later. Some of this is based on code by Tomasz Konojacki (xenu).
This fixes at least two problems: - unlike UCRT, the MSVCRT used for gcc builds has a bug converting a FILETIME in an unlike current DST state, returning a time offset by an hour. Fixes GH #6080 - the MSVCRT apparently uses FindFirstFile() to fetch file information, but this doesn't follow symlinks(), so stat() ends up returning information about the symlink(), not the underlying file. This isn't an issue with the UCRT which opens the file as this implementation does. Currently this code calculates the time_t for st_*time, and the other way for utime() using a simple multiplication and offset between time_t and FILETIME values, but this may be incorrect if leap seconds are enabled. This code also requires Vista or later. Some of this is based on code by Tomasz Konojacki (xenu).
This fixes at least two problems: - unlike UCRT, the MSVCRT used for gcc builds has a bug converting a FILETIME in an unlike current DST state, returning a time offset by an hour. Fixes GH #6080 - the MSVCRT apparently uses FindFirstFile() to fetch file information, but this doesn't follow symlinks(), so stat() ends up returning information about the symlink(), not the underlying file. This isn't an issue with the UCRT which opens the file as this implementation does. Currently this code calculates the time_t for st_*time, and the other way for utime() using a simple multiplication and offset between time_t and FILETIME values, but this may be incorrect if leap seconds are enabled. This code also requires Vista or later. Some of this is based on code by Tomasz Konojacki (xenu).
This fixes at least two problems: - unlike UCRT, the MSVCRT used for gcc builds has a bug converting a FILETIME in an unlike current DST state, returning a time offset by an hour. Fixes GH #6080 - the MSVCRT apparently uses FindFirstFile() to fetch file information, but this doesn't follow symlinks(), so stat() ends up returning information about the symlink(), not the underlying file. This isn't an issue with the UCRT which opens the file as this implementation does. Currently this code calculates the time_t for st_*time, and the other way for utime() using a simple multiplication and offset between time_t and FILETIME values, but this may be incorrect if leap seconds are enabled. This code also requires Vista or later. Some of this is based on code by Tomasz Konojacki (xenu).
This fixes at least two problems: - unlike UCRT, the MSVCRT used for gcc builds has a bug converting a FILETIME in an unlike current DST state, returning a time offset by an hour. Fixes GH #6080 - the MSVCRT apparently uses FindFirstFile() to fetch file information, but this doesn't follow symlinks(), so stat() ends up returning information about the symlink(), not the underlying file. This isn't an issue with the UCRT which opens the file as this implementation does. Currently this code calculates the time_t for st_*time, and the other way for utime() using a simple multiplication and offset between time_t and FILETIME values, but this may be incorrect if leap seconds are enabled. This code also requires Vista or later. Some of this is based on code by Tomasz Konojacki (xenu).
This fixes at least two problems: - unlike UCRT, the MSVCRT used for gcc builds has a bug converting a FILETIME in an unlike current DST state, returning a time offset by an hour. Fixes GH #6080 - the MSVCRT apparently uses FindFirstFile() to fetch file information, but this doesn't follow symlinks(), so stat() ends up returning information about the symlink(), not the underlying file. This isn't an issue with the UCRT which opens the file as this implementation does. Currently this code calculates the time_t for st_*time, and the other way for utime() using a simple multiplication and offset between time_t and FILETIME values, but this may be incorrect if leap seconds are enabled. This code also requires Vista or later. Some of this is based on code by Tomasz Konojacki (xenu).
|
This is (finally) fixed by b277e76. |
(This is thanks to perl core commit b277e767f3, which fixes CPAN RT#18513: See Perl/perl5#6080.) Also note that this module wasn't quite made redundant by VC14.0 because utime() still didn't work correctly on directories.
Migrated from rt.perl.org#18513 (status was 'stalled')
Searchable as RT18513$
The text was updated successfully, but these errors were encountered: