Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.0.6
-
None
-
None
-
Linux, Windows
Description
According to RFC 959 the line separator for ASCII files must always be CRLF (Carriage Return and Line Feed) when transferring. They can be later stored with the current OS's line separator (EOL - end of line). So the data is always received with CRLF as line separtor, then transformed by the FTP Server and stored with EOL instead of CRLF (on Windows EOL == CRLF, but on Linux EOL == LF). When downloading the file EOL must be replaced again by CRLF. I believe there are problems with both upload and download conversions.
For upload the current implementation transforms not only CRLF, but also single CRs and single LFs as CRLF. This corrupts the data if there are CRs which is part of the content.
For download the current implementation does not consider the current EOL, but always makes a transformation regardless whether it is running on Linux or on Windows. So it always converts LF to CRLF. If we are running on Windows and we receive a file where LF is part of the message and not a line separator, it will be modified to CRLF and thus will corrupt the data.