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:

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)?

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...