Archived Forum Post

Index of archived forum posts

Question:

Error settings remote file date, FTP2 does not support MFMT?

Feb 05 '15 at 17:09

It looks like FTP2 does not support widely supported MFMT command for setting remote file date. It only tries MDTM and SITE UTIME cmds like this:

[FileServer.TransferFile] - Upload file C:\temp\cgi-bin\123.txt -> /Upload/test/123.txt
[FTPServer.OnProgressInfo] - FtpCmdSent PASV
[FTPServer.OnProgressInfo] - FtpCmdResp 227 Entering Passive Mode (127,0,0,1,235,121)
[FTPServer.OnProgressInfo] - SocketConnect 127.0.0.1:60281
[FTPServer.OnProgressInfo] - SocketConnected 127.0.0.1:60281
[FTPServer.OnProgressInfo] - FtpCmdSent STOR /Upload/test/123.txt
[FTPServer.OnProgressInfo] - FtpCmdResp 150 Opening data channel for file upload to server of "/Upload/test/123.txt"
[FTPServer.OnProgressInfo] - PutFile Closing data connection.
[FTPServer.OnProgressInfo] - PutFile Reading final reply.
[FTPServer.OnProgressInfo] - FtpCmdResp 226 Successfully transferred "/Upload/test/123.txt"
[FileServer.SetFileDateStamp] - Set file '/Upload/test/123.txt' date to 8.11.2010 16:15:40
[FTPServer.OnProgressInfo] - FtpCmdSent MDTM 20101108161540 /Upload/test/123.txt
[FTPServer.OnProgressInfo] - FtpCmdResp 550 File not found
[FTPServer.OnProgressInfo] - FtpCmdSent SITE UTIME 20101108161540 /Upload/test/123.txt
[FTPServer.OnProgressInfo] - FtpCmdResp 504 Command not implemented for that parameter
[FileServer.SetFileDateStamp] - Failed to set file '/Upload/test/123.txt' date to 8.11.2010 16:15:40

I'm uploading to Filezilla server, and it only supports MFMT command. Basically this means that there is no way to set remote file date on filezilla server, or am I missing something?

If I am not, then I would hope MFMT will be implemented in near future. Do you think this would be possible?

Btw, Im using .net chilkat 9.5.0.46


Answer

Yes, Chilkat will implement this right away. What programming language, operating system, etc. do you use? When it's ready, I'll post a pre-release download URL here..


Answer

Wow, that was fast, may thanks for answer! I use C# .NET 4.51 on Visual Studio 2013, and I would be very happy to test this on my system when you got pre-release available for download. One additional thing to consider: It would be great if there would be some additional / optional parameter on FTP2.SetRemoteFileDateTime() where I could tell what command to use for setting date MDTM/UTIME/MFMT, so that FTP2 would not try the same sequence of these commands for each file (its kind a boring to get same error messages for all those 1.000.000 files I need to upload daily). Or maybe add FTP2.SetRemoteFileDateTimeEx(date, filename, command), where command would be enum AUTO=0, MDTM=1, UTIME=2, MFMT=3.


Answer

Here's a new build (v9.5.0.48 pre-release) that will automatically use MFMT if "MFMT" is listed in the features when connecting.

32-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet45-vs2013-9.5.0-win32.zip
64-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet45-vs2013-9.5.0-x64.zip

If MFMT is supported, it is used first, and the MDTM and UTIME commands won't be tried.


Answer

Incredibly fast action, many thanks for that! I tested new assembly, and it works almost, here is new log output:

5.2.2015 1:17:48 [0] [T:11 J:1390] [FileServer.TransferFile] - Upload file C:\temp\cgi-bin\123.txt -> /Upload/test/123.txt
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdSent PASV
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdResp 227 Entering Passive Mode (127,0,0,1,205,185)
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - SocketConnect 127.0.0.1:52665
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - SocketConnected 127.0.0.1:52665
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdSent STOR /Upload/test/123.txt
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdResp 150 Opening data channel for file upload to server of "/Upload/test/123.txt"
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - PutFile Closing data connection.
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - PutFile Reading final reply.
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdResp 226 Successfully transferred "/Upload/test/123.txt"
5.2.2015 1:17:48 [0] [T:11 J:1390] [FileServer.SetFileDateStamp] - Set file '/Upload/test/123.txt' date to 8.11.2010 16:15:40
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdSent MFMT 20101108161540 /Upload/test/123.txt
5.2.2015 1:17:48 [0] [T:11 J:1390] [FTPServer.OnProgressInfo] - FtpCmdResp 213 modify=20101108161540; /Upload/test/123.txt
5.2.2015 1:17:48 [0] [T:11 J:1390] [FileServer.SetFileDateStamp] - Success setting file '/Upload/test/123.txt' date to 8.11.2010 16:15:40

So MFMT cmd is sent properly (beautiful!), and log looks like everything is now fine. But there is a small problem, and I am not sure if its filezilla, or MFMT specs/cmd. The log shows that time portion of date is sent as 161540, ie. 16:15:40, and that is the time on local file. BUT end result is that file gets time 18:15:40 on server (server is running on the very same computer, so its on same time zone), so it looks like filezilla is assuming getting an UTC time (I'm in UTC-2 time zone). So if you would convert local file time -> UTC -> send MFMT cmd -> result would be correct. I think (not 100% sure) that MFMT spec says that all times should be represented in GMT/UTC. Also not sure if MDTM and SITE UTIME are using UTC or local time, but I'm quite sure that MFMT implementations on ftp servers are expecting UTC times. You might wanna double check that.


Answer

I did some research, and it seems to be quite clear, that MFMT times should always be in UTC. The draft The "MFMT", "MFCT", and "MFF" Command Extensions for FTP in

http://tools.ietf.org/html/draft-somers-ftp-mfxx-04#section-2.3

say that

"2.3. Times

This document defines times in the same manner as that as specified in section 2.3 of [2]. "

and this relates to RFC 3659 here:

http://tools.ietf.org/html/rfc3659#section-2.3

where it says:

Time values are always represented in UTC (GMT), and in the Gregorian
calendar regardless of what calendar may have been in use at the date
and time indicated at the location of the server-PI.

So I rest my case, datetime should always be in UTC. Of course I could do local time -> UTC convertion myself with simple:

var utc = dt.ToUniversalTime();
ftp.SetRemoteFileDateTime(utc, filename);

But as I dont know if chilkat FTP2 is sending MFMT command, this would also make conversion to UTC when FTP2 sends MDTM and SITE UTIME commands. I cannot recall if those commands should also use UTC.

I have been working with various file transfer protocols like FTP about 20 years, and I know that this datetime stuff is a total mess. Some server implementations expect UTC, and some expect local time. So its about impossible to make it work with all servers. But anyway, I hope this information helps you make an educated guess what is the best way to move forward with this.

So all in all, I am very happy with new MFMT command support, and I can always present an option in my software to use either UTC or local time with these commands. All I would need is a confirmation of how FTP2 is currently implemented, so does it always send local time with MFMT, MDTM and SITE UTIME commands (= never makes any conversions to UTC)?


Answer

Thanks! I'll get this sorted out today (hopefully).. I'll post here again when the fix is ready..


Answer

Check to see if this is the problem:

When you call "dt.ToUniversalTime", if "dt" is a DateTime structure where the "Kind" property is Unspecified (see https://msdn.microsoft.com/en-us/library/system.datetime.kind%28v=vs.110%29.aspx ) then you might be converting from something that is already UTC.

Make sure your DateTime variables are always created where the Kind property is never Unspecified.


Answer

Yes, sure, in the example I provided, dt converts nicely to UTC with dt.ToUniversalTime(). And with that local time -> UTC code, the MFMT code your provided in new FTP2 works fine and correctly w/ filezilla (and Serv-U and CerberusFTP etc.). So I can perfectly live with this solution. And I can provide my customers an option to select a) Send local time with SetDate b) Send UTC time with SetDate, and do local time -> UTC myself when a) or b) is selected by user. And I think this is how it should be, as we very well know that some FTP servers will always break all the rules, and nothing works with them, so having simple rule like this: chilkat FTP2 will always send date time as local time (known to normal C# etc. coders as the value of datetime) as-is. And if there is a need, developer can convert that local time to UTC if needed, in case they understand what the difference is. So that was my question in the end: does FTP2 always send local time with MFMT, MDTM and SITE UTIME commands (= never makes any conversions to UTC)? As if it does not mess with .ToUniversalDate() or such, then Im all fine and ready with current (=the build you provided) build.

Btw, you are doing a great job here w/ chilkat, really!

rgds, Matt