CkFtp reports wrong dates for files on some FTP servers.
There is an FTP server on AS/400 (not many more details) that responds to FEAT like this:
Commande : FEAT Réponse : 211-Feature listing follows: Réponse : AUTH TLS Réponse : CCC Réponse : PBSZ Réponse : PROT Réponse : 211 End of feature listing.So it does NOT support the MLSD command (which I think is the cause of the problem). If I understand correctly, CkFtp uses the LIST command in this case to get the file timestamps. The LIST command is not really meant for parsing, but for human eyes only.
A file created on the 2nd of August 2013 (2-8-2013 using d-m-yyyy format), the GetCreateDate method returns 8-2-2013, it switches the day and month. I looked at the documentation to see if I can somehow tell CkFtp how to interpret the date but could not find anything. Am I overlooking something?
Gert, write code that does the following:
1) Turn on verbose logging by setting the VerboseLogging property = true. Also set KeepSessionLog = true.
2) Write the standard FTP code to connect and authenticate with the FTP server.
3) Access the NumFilesAndDirs property (this causes the directory listing to be downloaded).
4) The directory listing received from the server should be available in either or both of the LastErrorText and SessionLog properties.
Post the directory listing here (or at least a few lines) so I can see what it looks like. Also, the LastErrorText will contain information indicating the FTP2 component's decision about the format it recognized. Internally, there are approx. a dozen different directory listing formats that are recognized and parsed. The information I need is to first ensure that the FTP2 component is using the correct AS/400 directory parsing code, and if so, then to check it for mistakes based on the data you provide.
Here is the requested info. Note that the file test_12aout2013.txt should have timestamp "12 august", but CK returned "8 december". The FTP server is in France.
IFtpImpl::getDirectoryList:ChilkatLog: NumFilesAndDirs: DllDate: Jul 15 2013 ChilkatVersion: 9.4.1.26 UnlockPrefix: WATCHDFTP Username: WEUSRV001:svc.fr.admin Architecture: Little Endian; 64-bit VerboseLogging: 1 FTP directory cache not fresh. Fetching dir listing... checkDirCache_listPattern: supportsMLSD: 0 initialGreeting: 220-QTCP at S44240DA.xxxxxx.NET. 220 Connection will close if idle more than 50 minutes. ListDir: Active transfer mode setupActiveDataSocket1: Using ephemeral port range for Active data connection. bindSockAddr: 0200 0000 0000 0000 0000 0000 0000 0000 Socket bind successful. dataPort: 51161 MyIPv4: 10,1,33,11,199,217 readFtpControlChannelReply: rcvUntilMatchStringQP: =0A dbReceived0: startIdx: 0 dbReceived: 200 PORT subcommand request successful.Found match string. --readFtpControlChannelReply SetupDataSocketTimeMS: 0 --setupActiveDataSocket1 SendingFtpCommand: sendingCommand: LIST --SendingFtpCommand ReadInitialReply2: readFtpControlChannelReply: rcvUntilMatchStringQP: =0A dbReceived0: startIdx: 0 dbReceived: 125 List started. Found match string. --readFtpControlChannelReply --ReadInitialReply2 listDirStatusCode: 125 listDirIntermediateReply: 125 List started. ReadFtpDataChannel: numBytesRequested: 4096 Connection closed by connected peer. dirListSize: 134 --ReadFtpDataChannel Data connection closed by server Possibly an empty directory listing... Looks like an AS/400 directory listing... AS/400 directory listing AS/400 directory listing readFtpControlChannelReply: rcvUntilMatchStringQP: =0A dbReceived0: startIdx: 0 dbReceived: 250 List completed. Found match string. --readFtpControlChannelReply ListTimeMS: 234 --ListDir rawDirListingQP: PC 868352 02/08/13 08:59:12 *DIR Archives/
PC 0 12/08/13 08:11:08 *STMF test_12aout2013.txt
--checkDirCache_listPattern N: 2 Success. --NumFilesAndDirs --ChilkatLog IFtpImpl::getDirectoryList:220-QTCP at S44240DA.xxxxxx.NET. 220 Connection will close if idle more than 50 minutes. . USER pc 331 Enter password. . PASS **** 230 PC logged on. . TYPE I 200 Representation type is binary IMAGE. . SYST 215 OS/400 is the remote operating system. The TCP/IP version is "V5R4M0". . FEAT 211-Feature listing follows: AUTH TLS CCC PBSZ PROT 211 End of feature listing. . SYST 215 OS/400 is the remote operating system. The TCP/IP version is "V5R4M0". . CWD /Home/M6/OUT 250-NAMEFMT set to 1. 250 "/Home/M6/OUT" is current directory. . PORT 10,1,33,11,199,217 200 PORT subcommand request successful. . LIST 125 List started.
(DirListingCharset: ansi) listing size = 134 PC 868352 02/08/13 08:59:12 DIR Archives/ PC 0 12/08/13 08:11:08 STMF test_12aout2013.txt 250 List completed. 220-QTCP at S44240DA.xxxxxx.NET. 220 Connection will close if idle more than 50 minutes. . USER pc 331 Enter password. . PASS **** 230 PC logged on. . TYPE I 200 Representation type is binary IMAGE. . SYST 215 OS/400 is the remote operating system. The TCP/IP version is "V5R4M0". . FEAT 211-Feature listing follows: AUTH TLS CCC PBSZ PROT 211 End of feature listing. . SYST 215 OS/400 is the remote operating system. The TCP/IP version is "V5R4M0". . CWD /Home/M6/OUT 250-NAMEFMT set to 1. 250 "/Home/M6/OUT" is current directory. . PORT 10,1,33,11,199,217 200 PORT subcommand request successful. . LIST 125 List started.
(DirListingCharset: ansi) listing size = 134 PC 868352 02/08/13 08:59:12 DIR Archives/ PC 0 12/08/13 08:11:08 STMF test_12aout2013.txt 250 List completed.
Also, according to the user (who had this same problem last month), tomorrow (13/08/13 - dd/mm/yy syntax), the file will get the timestamp 8 january 2014 (the month "13" will rollover to year).
I suspect CK interprets dates from the LIST command using the preferred American format (mm/dd/yy), but in this case it should use the common European format (dd/mm/yy). I have no idea how CK can determine this.
Probably the best solution is that you implement a method setListDateFormat so I can tell CK how to interpret the date.
I checked the internal code and found that it makes a distinction between US and European month/day order based on the delimiter ("/" vs. ".") In other words, if "/" is used, then it's "mm/dd/yy". If "." is used, then it's "dd.mm.yy".
This was probably a result of what was found through past experience.
I don't know of any good solution. Even the idea of allowing a user to set a date format wouldn't work because the date/time format can be different for different entries in a single directory listing.
The dot as a separator is used in some (most?) European countries. Holland uses a dash by default, I guess France a slash.
...Even the idea of allowing a user to set a date format wouldn't work because the date/time format can be different for different entries in a single directory listing.Are you sure? I think the format is based on how the FTP Server (or maybe the server it runs on) is setup. That should give you the same date format for all files in the LIST.