tool_operate: Fix --remote-time incorrect times on Windows. draft1 #1121
Conversation
- Use Windows API SetFileTime to set the file time instead of utime. We can't use utime on Windows because it may apply a daylight saving time offset to our UTC file time. Bug: https://curl.haxx.se/mail/archive-2016-11/0033.html Reported-by: Tim Closes xxx
|
@jay, thanks for your PR! By analyzing the history of the files in this pull request, we identified @yangtse, @bagder and @captain-caveman2k to be potential reviewers. |
| SetFileTime(hfile, NULL, (FILETIME *)&converted, | ||
| (FILETIME *)&converted); | ||
| CloseHandle(hfile); | ||
| } |
There was a problem hiding this comment.
Possibly showing an error message here in case of failure?
There was a problem hiding this comment.
I notice we don't do that for utime so I didn't do it here. I'm not sure why it's not done. If it should be done for one should it be done for both? How about fprintf(config->global->errors, "Failed to set modification times");
There was a problem hiding this comment.
Right, it should be done for both. I guess it happens so rarely people haven't noticed or cared.
There was a problem hiding this comment.
Ok. Also is there a preferred way to handle when 64-bit is available and what literal suffix to use? I'm not sure what is going to be portable across all Windows compilers. I guess I could use curl_off_t and CURL_SUFFIX_CURL_OFF_T
There was a problem hiding this comment.
Yeah, those are the ones we have. Do we actually have non-64bit capable windows/compilers people still around?
|
Oh, and maybe add a line to the FAQ about from which point in time this is fixed. |
|
I am thinking I will modify my code so the fix is only present when there's a >= 64-bit curl_off_t, and otherwise fallback to utime. The alternative is add functions that can do 64-bit arithmetic using only 32-bit integers. Thoughts? |
I think that's fine. It should be relatively rare with <64 bit curl_off_t on windows builds. |
- Use Windows API SetFileTime to set the file time instead of utime. Avoid utime on Windows if possible because it may apply a daylight saving time offset to our UTC file time. Bug: https://curl.haxx.se/mail/archive-2016-11/0033.html Reported-by: Tim Closes curl#1121
It was reported on the mailing list that
--remote-timeisn't working properly on Windows and the timestamp may be off.In the FAQ it says:
curl is using utime to do the modification. I tried these dates:
Last-Modified: Thu, 01 Jan 1970 00:00:30 GMT
curl filetime is 30 (correct), and it sets that using utime.
file's last modified FILETIME is 116444736300000000 (correct)
Last-Modified: Thu, 20 Aug 1970 11:33:50 GMT
curl filetime is 20000030 (correct) and it sets that using utime.
file's last modified FILETIME is 116644772300000000 (incorrect: Thu, 20 Aug 1970 12:33:50 GMT)
The FILETIME should actually be 116644736300000000.
Last-Modified is defined HTTP-date and must always be GMT/UTC. So I think we could set the FILETIMEs directly on Windows just by using SetFileTime instead.
My first take on this is attached, but it requires
i64as a literal suffix and 64-bit integers.Edit: Uploaded a build of draft1 at the reporter's request:
curl_pr1121_draft1.zip