Commons Net
  1. Commons Net
  2. NET-440

library throws an exception in case the SYST command is not known or the result is not known by the implementation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.1
    • Component/s: FTP
    • Labels:
      None

      Description

      The FTP client uses the SYST command to determine the list output.
      This can fail in two ways:

      • a ParserInitializationException in case the response of the server is not known by apache.

      Can't it just default to UNIX for these type of ftp servers?

        Activity

        Hide
        Sebb added a comment -

        The work-round is to not use auto-detect, but to specify the server type.

        I'm not sure it's a good idea to default to any particular OS if the command fails.

        Show
        Sebb added a comment - The work-round is to not use auto-detect, but to specify the server type. I'm not sure it's a good idea to default to any particular OS if the command fails.
        Hide
        Stef added a comment -

        That only works if known you the type of the server in advance. We use the library to connect to a lot of different FTP servers where the type of server is not known in advance. (And by server I mean devices in the field, with some unknown OS and FTP server which can be up to 20 years old).

        When it can not auto detect (for whatever reason), I'd say try some default formatting. You can always fail afterwards when parsing does not succeed?

        Show
        Stef added a comment - That only works if known you the type of the server in advance. We use the library to connect to a lot of different FTP servers where the type of server is not known in advance. (And by server I mean devices in the field, with some unknown OS and FTP server which can be up to 20 years old). When it can not auto detect (for whatever reason), I'd say try some default formatting. You can always fail afterwards when parsing does not succeed?
        Hide
        Sebb added a comment -

        If the property "org.apache.commons.net.ftp.systemType" is defined, the code will use that as the system type, instead of relying on the return from SYST.

        If the SYST returns a value, but the value is not currently recognised, then you can create a property file "/systemType.properties" which maps system types to the parser type or parser class.

        Using the wrong parser won't necessarily cause a parse failure - it may just return incorrect results, which is why I don't think it is safe to have a built-in default.

        However, it would be possible to have an optional default system type which is used if the SYST command fails.

        Show
        Sebb added a comment - If the property "org.apache.commons.net.ftp.systemType" is defined, the code will use that as the system type, instead of relying on the return from SYST. If the SYST returns a value, but the value is not currently recognised, then you can create a property file "/systemType.properties" which maps system types to the parser type or parser class. Using the wrong parser won't necessarily cause a parse failure - it may just return incorrect results, which is why I don't think it is safe to have a built-in default. However, it would be possible to have an optional default system type which is used if the SYST command fails.
        Hide
        Sebb added a comment -

        Added check for system property "org.apache.commons.net.ftp.systemType.default" if SYST commmand fails,

        Show
        Sebb added a comment - Added check for system property "org.apache.commons.net.ftp.systemType.default" if SYST commmand fails,
        Hide
        Stef added a comment -

        Thanks!

        Show
        Stef added a comment - Thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            Stef
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development