[
https://issues.apache.org/jira/browse/FTPSERVER-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15650144#comment-15650144
]
Ivo Matheis commented on FTPSERVER-474:
---------------------------------------
To provide a concrete use case showing the impact of the above written:
Linux FTP command line client transfers a Windows-formatted text file with CRLF
EOLs to the Apache FTP Server. Der file gets encoded in wireformat by the Linux
FTP Client resulting in all LF being transformed to CRLF. The CRs of the
original file are ignored by the FTP Client, so the EOLs in the file look like
this on the wire: CR+CRLF.
Apache FTP Server transforms this EOL combination to LF+LF. (The preceeding CR
is transformed to LF, and the CRLF is transformed to LF.) The file is
corrupted, as we have two EOLs instead of one.
> ASCII mode corrupts some files
> ------------------------------
>
> Key: FTPSERVER-474
> URL: https://issues.apache.org/jira/browse/FTPSERVER-474
> Project: FtpServer
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.6
> Environment: Linux, Windows
> Reporter: Georgi Andreev
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
