(no subject)

Page 1.0 of 1.16
  • Aleksey

    Aleksey - 2013-12-27

    Can't reproduce the bug on Win7 x64, nor on NTFS nor on a FAT disk.

    The problem probably is caused by incorrect FILETIME returned by the GetFileAttributesEx() call for files on FAT (FAT stores times in local time), see the MSDN article "File Times":
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

    I'm closing the bug because MS droped WinXP support. But if you write a patch, I consider it ;)

     
    Last edit: Aleksey 2013-12-27
  • Aleksey

    Aleksey - 2013-12-27
    • status: open --> closed-works-for-me
     
  • Liviu

    Liviu - 2013-12-27

    The bug still exists, it only looks different during the winter months ;-) when DST is off. The following is the output of two identical runs on an NTFS volume - except for the current date, first one outside DST, second one inside DST - copied from a Win7 x64 cmd prompt (run-as-admin in order for 'date' to work).



    C:\tmp>date /t
    Thu 12/26/2013

    C:\tmp>dir /a-d *.exe
    12/26/2012 02:00 AM 304,582 rhash-1.2.10.exe
    09/17/2013 01:08 AM 315,552 rhash-1.3.0.exe

    C:\tmp>rhash-1.3.0.exe --md5 --printf=%{mtime}\t%s\t%p\n -- *.exe
    02:00.58 2012-12-26 304582 rhash-1.2.10.exe
    02:08.48 2013-09-17 315552 rhash-1.3.0.exe

    C:\tmp>date 9/21/13

    C:\tmp>dir /a-d *.exe
    12/26/2012 03:00 AM 304,582 rhash-1.2.10.exe
    09/17/2013 02:08 AM 315,552 rhash-1.3.0.exe

    C:\tmp>rhash-1.3.0.exe --md5 --printf=%{mtime}\t%s\t%p\n -- *.exe
    02:00.58 2012-12-26 304582 rhash-1.2.10.exe
    02:08.48 2013-09-17 315552 rhash-1.3.0.exe



    Note that the 'dir' times shift by 1 hour, while the 'rhash' times stay the same. They match when the system date/time is in the same DST on/off state as the file timestamp itself - December in the first run, September in the second run. Without digging too deeply, I guess that the CRT 'localtime' works correctly (which rhash uses), while 'cmd' uses FileTimeToLocalFileTime incorrectly, against MS' own advice (http://support.microsoft.com/kb/129574).

    I think rhash is doing it right, so no patch warranted, but maybe a FAQ "if rhash displays some timestamps one hour off in Windows vs. cmd/explorer/etc, then that's just a known MS quirk".

     
    Last edit: Liviu 2013-12-27
  • Aleksey

    Aleksey - 2014-01-10

    By experimenting I've got that on Win7-x64 localtime() makes the same wrong conversion as the mentioned FileTimeToLocalFileTime() function, returning the same time as the Windows 'dir' command.

    Only Windows Explorer applies DST correctly.

    So it's really bug in the OS (in WinAPI and in the MS implementation of C library).

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks