1. If the server supports MDTM, but does not support MLSD, then the usual copying files from the panel to the panel, the TC does not use the MDTM/MFMT.
2. The time zone difference between the server and the client, is taken into account ONLY when synchronizing directories (although it should always be taken into account);
3. In FXP mode, TC never use MDTM/MFMT (even if both servers support MLSD and MDTM).
4. Deny change the time of the source files is not possible. Please add a checkbox or ini-file paramert for this purpose.
FTP time set problem
Moderators: white, Hacker, petermad, Stefan2
FTP time set problem
Last edited by Isica on 2013-09-25, 12:25 UTC, edited 2 times in total.
- ghisler(Author)
- Site Admin
- Posts: 48097
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
1. MDTM is meant for reading the timestamp, not for writing it. TC will use MDTM for writing only when the server reports:
MDTM YYYYMMDDHHMMSS
In TC 8.5 beta, you can now force to use MDTM by setting SpecialFlags=4096 in [General] section, or the section of the individual connection in wcx_ftp.ini.
2. This is currently impossible, except when using MLSD which sends the time stamp as UTC.
3. This isn't currently supported, sorry.
4. I will consider it
MDTM YYYYMMDDHHMMSS
In TC 8.5 beta, you can now force to use MDTM by setting SpecialFlags=4096 in [General] section, or the section of the individual connection in wcx_ftp.ini.
2. This is currently impossible, except when using MLSD which sends the time stamp as UTC.
3. This isn't currently supported, sorry.
4. I will consider it
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
1. I looked closely, when the TC uses MDTM/MFMT... And yet there are bugs.
In the directory synchronization dialog, check MDTM is always available - regardless of the capabilities of the server. And if you set this checkbox, MFMT will be called. This is a bug, but in my case, this call was successful!:
I propose to do automatic detection through a test call MFMT (without parameters): if return 501, so this feature is supported.
In normal copy from the panel to the panel all right. Server capabilities are taken into account, checkbox "Preserve file dates" is not available, and MFMT will not be called.
2. I meant that a timezone correction should be applied always immediately after receiving the directory through the LIST. Then the time will display properly on the panel will also, not only in the dialogue synchronization.
4. The idea of reverse time synchronization of downloaded files, I find unfortunate. This may be useful in the absence of the possibility of installing a file time on the server, but in this case, this should be optional! The information when the file is sometimes very important, and its loss can be very unpleasant!
Offering: add checkbox "reverse TimeSync."
In addition, when using LIST, I suggest using one of the following algorithms for comparing files:
a) always ignore the second, if the server they are equal to zero;
b) before the comparison, precise the times for these files on the server using MDTM (can be slow - with a large number of files, you should use this optional.)
In the directory synchronization dialog, check MDTM is always available - regardless of the capabilities of the server. And if you set this checkbox, MFMT will be called. This is a bug, but in my case, this call was successful!:
As you can see, the server can support MFMT, but do not tell us about it.Connect to: (25.09.2013 1:01:00)
hostname=p9-preview.awardspace.net
username=1474685_test
startdir=
p9-preview.awardspace.net=82.197.130.122
220 ::ffff:82.197.130.122 FTP server ready
USER 1474685_test
331 Password required for 1474685_test
PASS ***********
230 Welcome to your web hosting account!Please upload your web site inside the directory of the respective hostname.(If you wish to upload outside the hostname directories or delete them please make sure Directory Protection is set to OFF from your hosting control panel - File Manager section)
SYST
215 UNIX Type: L8
FEAT
211-Features:
MDTM
REST STREAM
SIZE
211 End
HELP SITE
214-HELP
CHGRP
214 CHMOD
OPTS UTF8 ON
500 OPTS UTF8 not understood
Connect ok!
PWD
257 "/" is the current directory
Get directory
TYPE A
200 Type set to A
PASV
227 Entering Passive Mode (82,197,130,122,192,140).
LIST
150 Opening ASCII mode data connection for file list
Download
Waiting for server...
226 Transfer complete
CWD /
250 CWD command successful
PWD
257 "/" is the current directory
Get directory
PASV
227 Entering Passive Mode (82,197,130,122,192,224).
LIST
150 Opening ASCII mode data connection for file list
Download
Waiting for server...
226 Transfer complete
CWD /
250 CWD command successful
PWD
257 "/" is the current directory
PWD
257 "/" is the current directory
Get directory
PASV
227 Entering Passive Mode (82,197,130,122,192,159).
LIST
150 Opening ASCII mode data connection for file list
Download
Waiting for server...
226 Transfer complete
TYPE I
200 Type set to I
PASV
227 Entering Passive Mode (82,197,130,122,192,7).
STOR test.bin
150 Opening BINARY mode data connection for test.bin
Upload: 1 bytes
226 Transfer complete
SIZE test.bin
213 1
Copied (25.09.2013 1:01:13): c:\temp\2\test.bin -> ftp://p9-preview.awardspace.net/test.bin 1 байт, 0 bytes/s
MFMT 20130924220004 test.bin
213 Modify=20130924220004; test.bin
I propose to do automatic detection through a test call MFMT (without parameters): if return 501, so this feature is supported.
In normal copy from the panel to the panel all right. Server capabilities are taken into account, checkbox "Preserve file dates" is not available, and MFMT will not be called.
2. I meant that a timezone correction should be applied always immediately after receiving the directory through the LIST. Then the time will display properly on the panel will also, not only in the dialogue synchronization.
4. The idea of reverse time synchronization of downloaded files, I find unfortunate. This may be useful in the absence of the possibility of installing a file time on the server, but in this case, this should be optional! The information when the file is sometimes very important, and its loss can be very unpleasant!
Offering: add checkbox "reverse TimeSync."
In addition, when using LIST, I suggest using one of the following algorithms for comparing files:
a) always ignore the second, if the server they are equal to zero;
b) before the comparison, precise the times for these files on the server using MDTM (can be slow - with a large number of files, you should use this optional.)
1.
2. When using LIST *1, you can't know what those times actually mean. They are usually in local time, but which timezone it is, who knows. But if server supports MDTM, TC could check the time of one file after connecting, to determine the difference between UTC (returned by MDTM) and time returned by LIST and then apply it to all other times, because the difference will be constant. Or as a last resort, there could be another option for time offset in connection properties.
--
*1 Supporting only LIST in 2013, when final MLSD specification (RFC) is from 2007 (and first draft from 1997)... sigh. What is the environment? Computer museum? ;)
So it's either server's fault or result of using some horribly outdated proxy without MLSD support, which filters unknown FEATs. And btw, if your server supports MFMT, it most likely also supports MLSD (but it also most likely won't work in case it's a proxy's fault).http://tools.ietf.org/html/draft-somers-ftp-mfxx-04 wrote:Where a server-FTP process supports the MFMT command, as specified here, it MUST include the response to the FEAT command
2. When using LIST *1, you can't know what those times actually mean. They are usually in local time, but which timezone it is, who knows. But if server supports MDTM, TC could check the time of one file after connecting, to determine the difference between UTC (returned by MDTM) and time returned by LIST and then apply it to all other times, because the difference will be constant. Or as a last resort, there could be another option for time offset in connection properties.
--
*1 Supporting only LIST in 2013, when final MLSD specification (RFC) is from 2007 (and first draft from 1997)... sigh. What is the environment? Computer museum? ;)
Yes, it's a good algorithm! I had wanted to write about it, but you are ahead of meif server supports MDTM, TC could check the time of one file after connecting, to determine the difference between UTC (returned by MDTM) and time returned by LIST and then apply it to all other times, because the difference will be constant.
![Smile :)](./images/smilies/icon_smile.gif)
However, paragraph 2 of my remarks is devoted to the correct application of existing information about the time zone (which the user has entered manually).
However, this is an important addition.
- ghisler(Author)
- Site Admin
- Posts: 48097
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
In the sync tool, if you check MDTM, TC will try MFMT first, and if it fails, use MDTM.
In the main program, TC will show the "Copy timestamp" option only if it KNOWS that the server supports it.
In the main program, TC will show the "Copy timestamp" option only if it KNOWS that the server supports it.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com