|
| | | Forum Newbie
Group: Forum Members
Last Login: 9/8/2004 2:42:00 PM
Posts: 2, Visits: 1 |
| I am writing a Windows Service in vb.net as part of an FTP interface to a third party company. The Windows Service is designed to download files from the third party company’s ftp server. My code works fine when downloading from their development FTP server, which is running Windows FTP Server. I am running into a problem when I run the service against their production FTP server, which is running WS_FTP 4.0.0. I am using NLST to get a list of files to download. WS_FTP responds with only one file even though there are many files in the directory. Is there any work-around for this? Is NLST fully supported in newer versions of WS_FTP? Thanks, Joe |
| |
| | | 
Time Traveler
Group: Moderators
Last Login: 7/16/2008 8:55:05 AM
Posts: 176, Visits: 9 |
| NLST seems to work fine for me. Are you writing the FTP interface from scratch? If so, are you sure that Windows FTP Server and WS_FTP Server aren't sending different new-line delimiters (i.e. "\r" versus just "" or "\r") and you're just trying to handle them the same? It's something to check out, at least. I'm pretty confident you can make it all the way to running an NLST before such a bug would show up in your code, since all the server responses for login are only one line long.
Brandon Felger
IMail Install Developer
Ipswitch |
| |
| | | Forum Newbie
Group: Forum Members
Last Login: 9/8/2004 2:42:00 PM
Posts: 2, Visits: 1 |
| Brandon, I did write this from scratch, along with some code I pulled from someone else. What I'm doing is, after logging in and changing to the appropriate directory, I open a socket, send the NLST command and the read from the socket. I don't know if you are familiar with vb.net but I am using the standard socket library. I am doing a socket.read into a buffer at 513 bytes at a time. On the Microsoft FTP server I receive a full 513 byte buffer (assuming there are enough files on the server, which in this case there are). There are 2 bytes delimiting the file names. On the WS_FTP server I am only receiving 36 bytes. The first file name is 34 bytes long and 2 bytes for the delimiter. I don't think I am interpreting the delimiters incorrectly when I p a r s e the buffer because I am only receiving one file name from the socket to begin with. Joe |
| |
| | |
Time Traveler
Group: Moderators
Last Login: 7/16/2008 8:55:05 AM
Posts: 176, Visits: 9 |
| I don't think I am interpreting the delimiters incorrectly
You already convinced me when you said you were only receiving 36 bytes. If a recv() returns 36 bytes, then 36 bytes is all you got. 
Two things that stick out in my mind: (1) the error message returned for not beign able to open a data connection (because WS_FTP Server likes to handle NLST on a data channel) is 33 bytes long, so suspiciously close to 36 I gotta ask if you verified that the 36 bytes received is the first file name. But I only ask "in case"; I'm sure you've looked at that already. The other question I have is whether a subsequent recv() call (or socket.read or whatever you're using) would return the other filenames. Again, I'm guessing not.
Try this: connect to WS_FTP Server using WS_FTP Pro or Home (if you don't have it, download an eval version) and examine (using a tool such as Ethereal) what happens when the client sends an NLST to WS_FTP Server. I'm confident that will give you a better idea of how WS_FTP Server expects an NLST call to be handled.
Of course, you can also purchase this very lovely WS_FTP Pro SDK from us.
Brandon Felger
IMail Install Developer
Ipswitch |
| |
|
|