We are using Core FTP LE (build 1447) and experiencing following problem:
After downloading with MDTM enabled the local timestamp mismatches the remote one. Disabling MDTM solves this issue in the downloading, but the Compare/Sync tool sets back the timestamp to the wrong value.
After some debugging I have found the place in the code, where the program sets the local filetime. It receives as parameter the timestamp in Unix format, the filename, and a flag showing if MDTM is set (I assume). It converts the timestamp to SYSTEMTIME and then it to FILETIME, which is passed to the SetFileTime function.
My questions are:
Question 1: Why does not the program call the LocalFileTimeToFileTime function with the FILETIME value received back from SystemTimeToFileTime? The SYSTEMTIME is in localtime (as it should be to show up correctly in the dirlist), but the FILETIME must be in UTC (at least on NTFS). The LocalFileTimeToFileTime would do the necessary conversion, and after calling it the FILETIME would be in UTC, thus setting the right timestamp.
Question 2: Disabling MDTM sets the flag (that is passed as parameter to the localfile timeset function) to 0 during downloading, and so the function does not call the SystemTimeToFileTime function, instead (I believe) computes the FILETIME directly from the Unix value. That is why the issue is solved with MDTM disabled, and the two timestamps are equal. But the Compare/Sync tool sets this flag hardcoded to 1, no matter, what is the MDTM settings, so the wrong conversion takes place. Why does not the tool take into account the state of MDTM disabling, as the downloading part of the program does it?
Sorry for the long text, but I think it could not be explained in a shorter way.
Thanks
Akos
Compare/Sync tool adjusts time incorrectly
Compare/Sync tool adjusts time incorrectly
Last edited by harleq on Sat Jun 17, 2006 7:38 am, edited 1 time in total.
I am using proftpd-1.3.0 and as I found after some research it really has an issue with MDTM as it does not always send the MDTM time in GMT, just with TimesGMT directive set to on. I will post them on their forum about this problem, so it should be solved on the server side. But this does not explain everything, and yet I think there can be an issue in CoreFTP too.
When I set TimesGMT to on, and MDTM passes back the right time in GMT, with MDTM enabled in CoreFTP the download timestamp is right, but when the Sync dialog sets only the timestamp (because the size did not change) it sets it wrongly.
With some debugging I found out, that after downloading the set_timestamp (or something like that) function in CoreFTP receives the timestamp in GMT (flag = 1), while by simple touching in the Sync tool it gets the same file's timestamp in localtime (flag is 1 in this case also), thus setting it wrongly.
For example:
MDTM data.dat
213 20060530073700
Time is in GMT, downloading the file sets its timestamp correctly to 2006.05.30. 09:37:00 (to our local time). When I set the timestamp of the local file manually (eg. with Total Commander) to something else, let's say to 2006.05.25 9:37, and then synchronize the local and the remote folders, the program notices the difference, tries to adjust the local file's timestamp, says it succeeded, but it is 2006.05.30 11:37, the local time for the 20060530093700 GMT. After debugging the code it seems obvious, that the Synchronizing part interprets the local timestamp as GMT, although it is already in localtime. As said, the download part passes the right GMT time even with flag 1 to the set_timestamp function.
I think the download and synchronizing part should always set the same filestamp to the very same file (with MDTM enabled in site configuration and the Compare/Sync dialog) regardless the MDTM is in GMT or localtime. As now it is not the situation, there may probably be a problem in the client side too.
When I set TimesGMT to on, and MDTM passes back the right time in GMT, with MDTM enabled in CoreFTP the download timestamp is right, but when the Sync dialog sets only the timestamp (because the size did not change) it sets it wrongly.
With some debugging I found out, that after downloading the set_timestamp (or something like that) function in CoreFTP receives the timestamp in GMT (flag = 1), while by simple touching in the Sync tool it gets the same file's timestamp in localtime (flag is 1 in this case also), thus setting it wrongly.
For example:
MDTM data.dat
213 20060530073700
Time is in GMT, downloading the file sets its timestamp correctly to 2006.05.30. 09:37:00 (to our local time). When I set the timestamp of the local file manually (eg. with Total Commander) to something else, let's say to 2006.05.25 9:37, and then synchronize the local and the remote folders, the program notices the difference, tries to adjust the local file's timestamp, says it succeeded, but it is 2006.05.30 11:37, the local time for the 20060530093700 GMT. After debugging the code it seems obvious, that the Synchronizing part interprets the local timestamp as GMT, although it is already in localtime. As said, the download part passes the right GMT time even with flag 1 to the set_timestamp function.
I think the download and synchronizing part should always set the same filestamp to the very same file (with MDTM enabled in site configuration and the Compare/Sync dialog) regardless the MDTM is in GMT or localtime. As now it is not the situation, there may probably be a problem in the client side too.
After some research the problem in boiled-down form:
The compare/sync tool adjusts the time wrongly, using GMT as local time.
If it downloads files, the time setting is correct, but in case it should only adjust the timestamp (there is no size difference) it sets it incorrectly.
The comparing part though runs error-free, interpreting the GMT as GMT and not local time. So the funny situation can happen, that the Sync tool finds timestamps incorrect, which it set just 10 seconds ago in a previous run.
(I changed the topic title as this issue does not seem to relate to MDTM.)
The compare/sync tool adjusts the time wrongly, using GMT as local time.
If it downloads files, the time setting is correct, but in case it should only adjust the timestamp (there is no size difference) it sets it incorrectly.
The comparing part though runs error-free, interpreting the GMT as GMT and not local time. So the funny situation can happen, that the Sync tool finds timestamps incorrect, which it set just 10 seconds ago in a previous run.
(I changed the topic title as this issue does not seem to relate to MDTM.)