You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Niklas Gustavsson (JIRA)" <ji...@apache.org> on 2008/11/06 20:52:52 UTC
[jira] Commented: (FTPSERVER-184) IODataConnection ASCII mode does
not work as expected.
[ https://issues.apache.org/jira/browse/FTPSERVER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645557#action_12645557 ]
Niklas Gustavsson commented on FTPSERVER-184:
---------------------------------------------
RFC 959 does specify the following:
In accordance with the NVT standard, the <CRLF> sequence
should be used where necessary to denote the end of a line
of text. (See the discussion of file structure at the end
of the Section on Data Representation and Storage.)
So, I think we're doing the right thing.
> IODataConnection ASCII mode does not work as expected.
> ------------------------------------------------------
>
> Key: FTPSERVER-184
> URL: https://issues.apache.org/jira/browse/FTPSERVER-184
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.0-M2, 1.0-M3
> Reporter: David Latorre
> Assignee: Niklas Gustavsson
> Fix For: 1.0-M4
>
>
> New lines in files sent in ASCII mode are transformed into /r/n no matter what platform the ftp server is running on. But if I'm not wrong, the new EOL should be equal to "line.separator" . If ASCII mode is going to be supported, this ought to be changed.
>
> The code in IODataConnection.transfer()
> {
> if (isAscii) {
> for (int i = 0; i < count; ++i) {
> byte b = buff[i];
> if (b == '\n' && !lastWasCR) {
> bos.write('\r');
> }
> if (b == '\r') {
> lastWasCR = true;
> } else {
> lastWasCR = false;
> }
> bos.write(b);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.