This patch should fix bug# 27633.
The messed up line endings in the output was caused by *some* servers
prefixing every '\n' with a '\r' so if the remote file already had
windows style line endings the data in the buffer was "\r\r\n" and the
existing code didn't handle this correcly. I have tested this against
vsftpd, ws-ftpd, warftp, os400 ftp, and successfully transferred files
with both *nix and win32 style line endings correctly.
As a side note...
The problem that a dot hoekstra at boxitbv dot nl expressed where large
files would be truncated, I believe was caused by the last characters in
the buffer being a line ending. On the next iteration of the loop it
would write all the nulls at the end of the buffer to the stream?? I saw
this twice in my testing. The rest of the data was there, it was just
after a bunch of nulls. So it wasn't truncated per se, the filesize was
actually significantly larger, but I can see how it could *appear*
truncated. After this patch I transferred several megs of data and
didn't see this, but YMMV on this one! If it's still a problem let me
know and I will look at it.
Jess
P.S. As this is the first time I have contributed anything publicly with
my name attached, constructive critsism of my code is welcome, but
please be gentle. ;)
