FtpServer
  1. FtpServer
  2. FTPSERVER-414

STAT / creates invalid directory listing (with Patch)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.5
    • Fix Version/s: 1.0.6, 1.1.0
    • Component/s: Server
    • Labels:
      None

      Description

      Some ftp clients (e.g. Cyberduck on Mac OS X) use the STAT command to list directores. The reply contains an invalid status code in the last line, which causes the ftp client to ignore the last line. So the last file in the directory does not show up in the ftp client listing:

      614869 [pool-3-thread-6] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - RECEIVED: STAT /
      615085 [pool-3-thread-6] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200--w------ 1 rototor@rototor.de rototor@rototor.de 21581 Jan 1 1970 uxz.pdf
      -w------ 1 rototor@rototor.de rototor@rototor.de 5788 Jan 1 1970 abc.pdf
      -w------ 1 rototor@rototor.de rototor@rototor.de 415447 Jan 1 1970 def.pdf
      200 -w------ 1 rototor@rototor.de rototor@rototor.de 822782 Jan 1 1970 xyz.pdf

      I dont know if this is a bug in the ftp client. But at least the following patch to the STAT command fixes the problem for me:

      diff --git a/org/apache/ftpserver/command/impl/STAT.java b/org/apache/ftpserver/command/impl/STAT.java
      index 19674b2..5ca76c1 100644
      — a/org/apache/ftpserver/command/impl/STAT.java
      +++ b/org/apache/ftpserver/command/impl/STAT.java
      @@ -77,10 +77,6 @@ public class STAT extends AbstractCommand {

      String dirList = directoryLister.listFiles(parsedArg,
      session.getFileSystemView(), LIST_FILE_FORMATER);
      + // DefaultFtpReply prepends the status code to the last line.
      + // This causes the STAT directory listing to loose the last directory entry in some clients
      + // e.g. Cyberduck
      + dirList += " \n";

      session
      .write(new DefaultFtpReply(

      With this patch applied the output looks like this:

      615085 [pool-3-thread-6] INFO org.apache.ftpserver.listener.nio.FtpLoggingFilter - SENT: 200--w------ 1 rototor@rototor.de rototor@rototor.de 21581 Jan 1 1970 uxz.pdf
      -w------ 1 rototor@rototor.de rototor@rototor.de 5788 Jan 1 1970 abc.pdf
      -w------ 1 rototor@rototor.de rototor@rototor.de 415447 Jan 1 1970 def.pdf
      -w------ 1 rototor@rototor.de rototor@rototor.de 822782 Jan 1 1970 xyz.pdf
      200

      And know the clients work correctly.

        Activity

        Hide
        Niklas Gustavsson added a comment -

        Do you get the same problem for other multiline replies, like MLST?

        Show
        Niklas Gustavsson added a comment - Do you get the same problem for other multiline replies, like MLST?
        Hide
        Emmeran Seehuber added a comment -

        I dont think so. At least other ftp clients (i.e. DirectoryOpus, FileZilla), which issue MLSD commands, work. I think the problem here is that the directory listing is transfered with the control connection, and gets "standard" control connection status replies inserted into the last line (see DefaultFtpReply).

        The workaround in the patch just fixed STAT enough to get it working with Cyberduck. I have no clue if this is the correct fix.

        Show
        Emmeran Seehuber added a comment - I dont think so. At least other ftp clients (i.e. DirectoryOpus, FileZilla), which issue MLSD commands, work. I think the problem here is that the directory listing is transfered with the control connection, and gets "standard" control connection status replies inserted into the last line (see DefaultFtpReply). The workaround in the patch just fixed STAT enough to get it working with Cyberduck. I have no clue if this is the correct fix.
        Hide
        Niklas Gustavsson added a comment -

        The reason for asking is if we should change this for all multi-line replies, or only for STAT. We're compliant with the RFC as far as I can tell, so this is likely a bug in Cyberduck. Have you reported this to the Cyberduck devs?

        That said, the RFC says that test on the last line is optional, so I would think that the patch would work.

        From the RFC:

        Thus the format for multi-line replies is that the first line
        will begin with the exact required reply code, followed
        immediately by a Hyphen, "-" (also known as Minus), followed by
        text. The last line will begin with the same code, followed
        immediately by Space <SP>, optionally some text, and the Telnet
        end-of-line code.

        For example:
        123-First line
        Second line
        234 A line beginning with numbers
        123 The last line

        Show
        Niklas Gustavsson added a comment - The reason for asking is if we should change this for all multi-line replies, or only for STAT. We're compliant with the RFC as far as I can tell, so this is likely a bug in Cyberduck. Have you reported this to the Cyberduck devs? That said, the RFC says that test on the last line is optional, so I would think that the patch would work. From the RFC: Thus the format for multi-line replies is that the first line will begin with the exact required reply code, followed immediately by a Hyphen, "-" (also known as Minus), followed by text. The last line will begin with the same code, followed immediately by Space <SP>, optionally some text, and the Telnet end-of-line code. For example: 123-First line Second line 234 A line beginning with numbers 123 The last line
        Hide
        Emmeran Seehuber added a comment -

        No, I have not yet reported this problem to the Cyberduck devs, as I didnt know if it was their bug. Also I need the ftp server to work with the ftp clients which are now out in the field.

        Show
        Emmeran Seehuber added a comment - No, I have not yet reported this problem to the Cyberduck devs, as I didnt know if it was their bug. Also I need the ftp server to work with the ftp clients which are now out in the field.
        Hide
        Sebb added a comment -

        The format of the output looks correct, however according to the RFC 959 the status code should be one of

        STAT
        211, 212, 213
        450
        500, 501, 502, 421, 530

        where

        211 System status, or system help reply.
        212 Directory status.
        213 File status.

        200 is not a valid reply status, as far as I can tell

        Show
        Sebb added a comment - The format of the output looks correct, however according to the RFC 959 the status code should be one of STAT 211, 212, 213 450 500, 501, 502, 421, 530 where 211 System status, or system help reply. 212 Directory status. 213 File status. 200 is not a valid reply status, as far as I can tell
        Hide
        Niklas Gustavsson added a comment -

        Right, that's been reported in FTPSERVER-413, albeit my fix used incorrect reply codes. Now fixed.

        Show
        Niklas Gustavsson added a comment - Right, that's been reported in FTPSERVER-413 , albeit my fix used incorrect reply codes. Now fixed.
        Hide
        Sebb added a comment -

        Actually, I think the data should not be on the status line(s).

        Some other FTP servers return data as follows (only first part of lines shown):

        212- Status of /:
        total 16
        drwxr-xr-x 2 0
        ...
        drwxr-xr-x 2 0
        212 End of status.

        That uses the correct status codes.

        213-Status follows:
        drwxr-xr-x 14 ftp
        ...
        drwxrwsr-x 23 ftp
        213 End of status

        Wrong status code used (should be 212)

        211-Status of /:
        drwxr-xr-x 4 ftp
        ...
        lrw-r-r- 1 ftp
        211 End of status

        Wrong status code (should be 212) and leading spaces not required.

        The parameterless STAT command behaves as follows in Apache FTPserver:

        ftp> quote STAT
        211-Apache FtpServer
        Connected to 127.0.0.1
        Connected from 127.0.0.1
        Logged in as anonymous
        211 End of status.

        That uses the correct status code, and the main content is between the 211 codes.
        I think the directory and file status codes should behave similarly (but with codes 212 and 213 of course).

        Show
        Sebb added a comment - Actually, I think the data should not be on the status line(s). Some other FTP servers return data as follows (only first part of lines shown): 212- Status of /: total 16 drwxr-xr-x 2 0 ... drwxr-xr-x 2 0 212 End of status. That uses the correct status codes. 213-Status follows: drwxr-xr-x 14 ftp ... drwxrwsr-x 23 ftp 213 End of status Wrong status code used (should be 212) 211-Status of /: drwxr-xr-x 4 ftp ... lrw-r- r - 1 ftp 211 End of status Wrong status code (should be 212) and leading spaces not required. The parameterless STAT command behaves as follows in Apache FTPserver: ftp> quote STAT 211-Apache FtpServer Connected to 127.0.0.1 Connected from 127.0.0.1 Logged in as anonymous 211 End of status. That uses the correct status code, and the main content is between the 211 codes. I think the directory and file status codes should behave similarly (but with codes 212 and 213 of course).
        Hide
        Niklas Gustavsson added a comment -

        Excellent, thanks for this analysis.

        Now fixed in rev 1129664 and 1129665.

        Show
        Niklas Gustavsson added a comment - Excellent, thanks for this analysis. Now fixed in rev 1129664 and 1129665.

          People

          • Assignee:
            Niklas Gustavsson
            Reporter:
            Emmeran Seehuber
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development