Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
This is on an FTP server that doesn't support MLSD, so CkFTP uses the LIST command to get directory entries. My program downloads new files from FTP servers by comparing the directory listings from "previous directory scan" to the "current directory scan".
It seems that either the FTP server or the chilkat component sometimes (once every XXX scans, not often) gives strange (partly truncated) LIST results. I use get_NumFilesAndDirs (and other functions) to work on the directories, Here is the session log of a normal LIST:
20131111 181948 drwxr-xr-x 11 p687233-1 ftpusers 4096 Oct 11 10:58 . 20131111 181948 drwxr-xr-x 11 p687233-1 ftpusers 4096 Oct 11 10:58 .. 20131111 181948 drwx---r-x 3 p687233-1 ftpusers 17 Oct 11 10:58 Rechnungen 20131111 181948 -rw-r--r-- 1 p687233-1 ftpusers 1288052 Jan 10 2013 UHU.jpg 20131111 181948 drwxr-xr-x 2 p687233-1 ftpusers 4096 Oct 4 12:15 Urlaub 20131111 181948 drwxr-xr-x 2 p687233-1 ftpusers 4096 Feb 13 2013 Vorlagen 20131111 181948 drwxr-xr-x 5 p687233-1 ftpusers 101 Nov 6 16:40 Wolf 20131111 181948 -rw----r-- 1 p687233-1 ftpusers 35384 Jul 1 2011 bank-gothic-light-bt.ttf 20131111 181948 drwxr-xr-x 2 p687233-1 root 21 Mar 13 2012 logs 20131111 181948 -rw-r--r-- 1 p687233-1 ftpusers 454656 Feb 8 2013 putty.exe 20131111 181948 -rw-r--r-- 1 p687233-1 ftpusers 246808 Jul 4 2011 snapshot.exe 20131111 181948 -rw-r--r-- 1 p687233-1 ftpusers 428 Jan 26 2013 swr3.fpl 20131111 181948 226 Transfer complete
Some time later my program lists the directory again, and now I see this in the log:
20131111 183127 drwxr-xr-x 11 p687233-1 ftpusers 4096 Oct 11 10:58 . 20131111 183127 drwxr-xr-x 11 p687233-1 ftpusers 4096 Oct 11 10:58 .. 20131111 183127 drwx---r-x 3 p687233-1 ftpusers 17 Oct 11 10:58 Rechnungen 20131111 183127 -rw-r--r-- 1 p687233-1 ftpusers 1288052 Jan 10 2013 UHU.jpg 20131111 183127 drwxr-xr-x 2 p687233-1 ftpusers 4096 Oct 4 12:15 Urlaub 20131111 183127 drwxr-xr-x 2 p687233-1 ftpusers 4096 Feb 13 2013 Vorlagen 20131111 183127 drwxr-xr-x 5 p687233-1 ftpusers 101 Nov 6 16:40 Wolf 20131111 183127 -rw----r-- 1 p687233-1 ftpusers 35384 Jul 1 2011 bank-gothic-light-bt.ttf 20131111 183127 drwxr-xr-x 2 p687233-1 root 21 Mar 13 2012 logs 20131111 183127 -rw-r--r-- 1 p687233-1 ftpusers 454656 Feb 8 2013 putty.exe 20131111 183127 -rw-r--r-- 1 p687233-1 ftpusers 246808 Jul 4 2011 snap226 Transfer complete
Note the last line.... the "226 Transfer complete" is on the same line as a directory entry. The original "snapshot.exe" and "swr3.fpl" files are now not "seen" by my program (get_NumFilesAndDirs and getFilename). CkFtp reports a "new file" called "snap" that obviously does not exist.
Is this a problem of the FTP server? Can you check to make sure the CkFTP component isn't causing this (I am using 9.4.1.55 at the moment). If this is caused by the FTP server, is there a way I can detect this, so I know it is a directory listing I can not trust (can you add a isTruncatedDirectoryList property)?
Thanks, Gert
Gert,
There is no reason to suspect that the CkFTP object is causing it. Internally, at the point of reading the incoming directory listing on the data connection, it simply reads the incoming bytes on the socket until there are no more (i.e. the server closes its side of the connection). It calls a single internal method to do this, and this is a method called by many other Chilkat objects -- so if it was defective in some way, we'd be getting problem reports from elsewhere. In other words, it's an incredibly low probability that the problem is within Chilkat.
Yes, I thought so much, it is probably caused by the FTP server (or sockets or...).
Is CkFtp perhaps looking for the string "226 xxxxxx" (or some variant) to determine the end of the directory list? I think a normal LIST would have a linefeed just before "226 xxxx" and CkFTP can check for this.
As it works now, CkFtp reports a wrong directory listing (caused by a wrong LIST result created by the FTP obviously). Can you leave this the way it works now (perhaps after retrying the LIST once or twice) but expose some boolean property I can inspect (isUnreliableDirectoryList()) that tells me if the "226 xxxx" response was on a line of its own (likely a good LIST result) or somewhere "in the middle" of the LIST result (like the 2nd LIST output above).
Several of my customers reported this problem behavior to me. They all say it is very sporadic (maybe once a week) but it causes big problems for them...
Thanks for considering. Gert
Gert,
I don't know what version you're using, but try this latest just to make sure it's nothing in a short-lived pre-release..
32-bit: http://www.chilkatsoft.com/preRelease/chilkat-9.4.1-x86-vc9.zip
64-bit: http://www.chilkatsoft.com/preRelease/chilkat-9.4.1-x86_64-vc9.zip