mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivo Matheis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FTPSERVER-474) ASCII mode corrupts some files
Date Wed, 09 Nov 2016 08:09:58 GMT

    [ 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

This message was sent by Atlassian JIRA

View raw message