Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

file ftp'd in binary, rcvd in ascii.

Status
Not open for further replies.

c2ssupport

Technical User
Mar 18, 2005
9
US
We're stuck with this one. Someone is sending us a tif image in binary mode(according to their logs) but we're receiving it in ASCII. The file is always 100 bytes or less smaller than what it should be. It is going through a couple of routers, etc. but nothing that should be changing the transfer mode, according to the sender anyway. Any help is greatly appreciated.

mike d.
 
You might also supply the source and destination operating system types and versions, FTP client used (presuming it's FTP) and FTP daemon used?

Annihilannic.
 
If you're using ftpd of redhat distrib taht's normal ans set like that for security reasons, you'll have to change it in the ftpd config file.
 
Sorry I didn't mention, this is an FTP process. The recipient is Solaris, not sure what the sender is using, but it's not command like, I think he said he's using an ocx?
 
I second feherke's suggestion, if the customer can upload the file successfully from command-line FTP then it narrows down the issue to the method they are using to send the file.

Annihilannic.
 
This is happening randomly, so if it was a setting on the recipient side, wouldn't it happen consistently?
What is it in ftpd that could do this?
 
Without wishing to sound too cynical are you sure that the guys at the other end know what they're doing. We see endless posts about the LF<->CR/LF conversion problem and in my experience far too many people are unaware that there may be any issues transferring files between Windows and *nix platforms.

OK, so they're logs say that the file was transferred in binary mode, but are you sure that the file wasn't corrupted as it was transferred from their work server to their export server. I speak from bitter experience!

I don't know what rules you have to abide by but it's pretty easy to fix by running the file through a utility like dos2unix. You would be pretty unlucky if using dos2unix broke a genuine binary file. The odds of getting a CR/LF combination in random data are pretty low.

Columb Healy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top