Downloaded text file from FTP is one long string

Hello,

I have code that is working correctly to download a text file from an FTP server, however that text file comes across as one big long run-on string.  The text file I'm downloading is a listing of access codes delimited by a carriage return, which i eventually need to modify and re-upload, so the file needs to stay in-tact in regards to the formatting of it.  Is there any way to download the file as-is and not have it return as a big pile of characters?  This is my first attempt at pulling down a file from FTP so I'm hoping there is just something easy I am missing.

The code I am using currently to get the file and save it is:

string serverpath = "ftp://ftpsite.com/codefile.txt";

FtpWebRequest request = (FtpWebRequest)WebRequest.Create(serverpath);
request.Method = WebRequestMethods.Ftp.DownloadFile;
request.Credentials = new NetworkCredential("username", "password");

FtpWebResponse response = (FtpWebResponse)request.GetResponse();
Stream responseStream = response.GetResponseStream();
StreamReader reader = new StreamReader(responseStream);

StreamWriter writer = new StreamWriter("Y:\\downloadedCodeFile.txt");
writer.Write(reader.ReadToEnd());

writer.Close();
reader.Close();
response.Close();

Thanks,
Joe
sglewAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
AlexPaceConnect With a Mentor Commented:
Don't forget that he has to re-upload the changed files so all that would have to be done in reverse after doing whatever modifications he does.

The FTP specification says that servers are responsible for changing the line endings to CRLF for transfers done in ASCII mode and almost all servers are compliant in that regard...  Transferring in binary and manually re-inflating the line endings is certainly an option but it seems like a waste of time when you could just do the transfer in ASCII in the first place by doing something like this:
request.UseBinary = false;

... anyway, while on the topic of "not elegant, but handy" .... you could download copies of the unix2dos and dos2unix utilities... save the string as a file... run unix2dos on it to get your line endings back... do your modifications... run dos2unix to change the line endings back to a format that the remote site will understand... then upload it in binary.  heh,
0
 
AlexPaceCommented:
Try transferring the file in ASCII mode.  That will cause the server to convert the line endings to CRLF so they will appear "normal" in Windows.  Do it when you re-upload too so the server can translate the line endings back into its native format.
0
 
frankhelkCommented:
Hmm - how deep have you inspected the resulting file ?

Does it still contain the original CR characters (which might be suppressed in display by your editor) or did those CRs stripped ?

If the characters are still in it, I would try to read / write the data not as a big blob but line by line, which might need possibly with some kind of end-of-line detection setting.

If the data file is not that big, I would try another attempt:
Transfer the data in binary mode into a big String object,

try to detect the EOL mode (CR / CR-LF) by searching for CR-CF in it,
then use String.Split(...) to make an array on Strings as Lines from it and finally
use File.WriteAll() to put the data into a disk file
Not elegant, but handy.
0
 
sglewAuthor Commented:
Bingo, that was it!  I figured it was probably something easy that I was missing.  Setting the UseBinary attribute to false allowed the file to save as expected.

Thanks AlexPace.

-Joe
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.