FtpServer
  1. FtpServer
  2. FTPSERVER-184

IODataConnection ASCII mode does not work as expected.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-M2, 1.0.0-M3
    • Fix Version/s: 1.0.0-M4
    • Component/s: Core
    • Labels:
      None

      Description

      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);
      }
      }
      }

        Activity

        Hide
        Niklas Gustavsson added a comment -

        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.

        Show
        Niklas Gustavsson added a comment - 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.
        Hide
        David Latorre added a comment -

        Hello,

        Sure you are right here, I didn't make myself clear enough Im sorry.

        As you (and RFC959) say, when we are sending the file we should transform to NVT-ASCII but not when we are receiving the file. In this second case, i think that the expected behaviour is that the text message be written to a file with the default line separator for the platform.

        The sender converts the data from an internal character
        representation to the standard 8-bit NVT-ASCII
        representation (see the Telnet specification). The receiver
        will convert the data from the standard form to his own
        internal form.

        Actually , according to the spec before a RETR ASCII operation is transformed we should be converting the charset to ASCII , for our machine could be using EBCDIC to store files and clients are supposed to expect that files are encoded in NVT-ASCII.

        So I don't know ... Any way, this has little priority for me (until someone using a non-ascii-compatible encoding complains) so we could leave this for the future. Any way I don't like ASCII mode for it breaks the 'REST' command. My implementation only supports binary mode.

        Show
        David Latorre added a comment - Hello, Sure you are right here, I didn't make myself clear enough Im sorry. As you (and RFC959) say, when we are sending the file we should transform to NVT-ASCII but not when we are receiving the file. In this second case, i think that the expected behaviour is that the text message be written to a file with the default line separator for the platform. The sender converts the data from an internal character representation to the standard 8-bit NVT-ASCII representation (see the Telnet specification). The receiver will convert the data from the standard form to his own internal form. Actually , according to the spec before a RETR ASCII operation is transformed we should be converting the charset to ASCII , for our machine could be using EBCDIC to store files and clients are supposed to expect that files are encoded in NVT-ASCII. So I don't know ... Any way, this has little priority for me (until someone using a non-ascii-compatible encoding complains) so we could leave this for the future. Any way I don't like ASCII mode for it breaks the 'REST' command. My implementation only supports binary mode.
        Hide
        Niklas Gustavsson added a comment -

        David, would you like to work on this for M4 or should we reschedule it for now? I do think we should fix this, but it could be done for 1.0

        Show
        Niklas Gustavsson added a comment - David, would you like to work on this for M4 or should we reschedule it for now? I do think we should fix this, but it could be done for 1.0
        Hide
        Niklas Gustavsson added a comment -

        We now store files sent in ascii mode with the local line endings (rev 721551).

        Show
        Niklas Gustavsson added a comment - We now store files sent in ascii mode with the local line endings (rev 721551).

          People

          • Assignee:
            Niklas Gustavsson
            Reporter:
            David Latorre
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development