I tried fetching/putting a windows-style text file (between a solaris server and my local linux box) using ascii mode with both Net::FTP and the command-line ftp utility. They both preserved the "\r\n" line terminations in the text file.

I noticed that the alleged "ascii" mode transfer actually causes more bytes to be transmitted -- a remote file with 20162 bytes (including 278 \r's and 279 \n's) reports 20441 bytes sent, whereas a binary transfer reports exactly 20162 bytes. Alas, both methods leave me with a 20162-byte file (i.e. no difference in the local copy). Anyway, it might not be the fault of the perl module.

I saw nothing in Net::FTP that would allow sending/getting data using a scalar variable as if it were a local file -- this would be a neat feature if it were available, and would give you a work-around for this problem.

I thought about trying to use a file handle instead of a file name, given that the file is set to ":crlf" with binmode, but that didn't seem to have any effect on the ftp transfer either.

You might consider using Archive::Tar to create a tar file for each distinct type of recipient host -- this allows you to control the line-term behavior of files being assembled into the tar set, and you have just one file to push to each receiver in binary mode (could even have Archive::Tar create the file in compressed form). But it seems a shame to add this much overhead before and after the transfer -- create the tar file, delete it when the transfer's done, unpack then delete the tar file at each recipient host.

The only other recourse would be to create an alternative form of Net::FTP (a derived class module, or simply a replacement) where you redefine the internal "_store_cmd()" method, so that it does the right thing instead of (or supplementing) the current "sysread()" call on the local file being sent (or maybe even support the use of a scalar that holds file content rather than using a file name or file handle).