Binary FTP file transfer using Internet Transfer Control

[Menthos]

Ok, here's my problem. I've written an app to pull down files from an FTP site using the internet transfer control. The app works fine, apart from the fact that the files that are downloaded lose the Carriage Return char (OD) from the ends of the lines. The line feed (OA) is there just fine.

If I manually FTP them from the server with a DOS session, setting the transfer mode to Binary then the file(s) arrive correctly formatted.

I've tried setting the Getchunk to icByteArray and PUTting the chunks to a file opened as binary, but that doesn't seem to change anything.

Anyone got any ideas as to where I'm going wrong? or how to make sure the file is retrieved intact?

Cheers in advance,

Menthos

 

[ArtieChoke]

I suspect your FTP host is a UNIX site. Only linefeeds are used to denote the end of a line in text files. I'm not sure why using FTP on the command line would change a linefeed to cr/lf, especially in binary mode. It's possible the FTP program converts to the proper end of line characters for DOS/Windows text files.

I had the same problem. I wrote a routine that split up the lines by looking for the linefeed character. You could probably do it easier by using the split function and use the linefeed as the delimiter. Then write out all the lines to your file from the array. This assumes your file can be contained completely in a single string. If not, process each chunk and replace lf w/ cr/lf.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[Menthos]

Yup, you're right, the site is a Unix box, however the files are sitting on it with the CR/LF's correctly.
I know if I were to pull the files down using an Ascii transfer, that they would strip the CR's out, hence using binary mode when manually transferring.

ITC would appear to be using Ascii mode to transfer, and there doesn't appear to be any way to force it to transfer in binary.

I'll throw it back out to the community - hopefully someone will have the answer....or a definitive NO

 

[ArtieChoke]

When you say "the files are sitting on it with the CR/LF's correctly" - how do you know there is actually a CR value in the file? Have you logged onto that machine and dumped the file in binary? Unless the file is being processed especially for Windows, UNIX text files only use linefeeds for the end of the line.

I just checked the MS site and ITC ONLY supports binary transfer, as I suspected. The reason you get the proper cr/lf combo when you do it manually is the FTP client does the conversion in ASCII mode (I think you have it backwards in your description above). Binary will send the file as-is - byte for byte.

The only way you can do it with the ITC is as I described above. Otherwise, you can use the FTP API calls, which do support ASCII mode.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[Menthos]

Yes, the files have been checked via a hex editor and the CR/LF's are present at the ends of lines on the Unix box.

Nope to having it backwards on the manual downloads. I'm using a DOS session to manually retrieve the file, and I'm physically setting the transfer mode to Binary. Some research that I've done points to ASCII mode making conversion changes based on file type, whereas, as you say, Binary mode transfers the file byte for byte. ASCII mode doesn't use the full 8 bits for byte transfers (I believe).

It's looking highly likely that this is going to have to be an API call solution and ditch the ITC approach (unfortunately).

Cheers,

Menthos