[jira] [Commented] (FTPSERVER-474) ASCII mode corrupts some files

["Ivo Matheis (JIRA)" <ji...@apache.org>]

    [ 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)