Uploaded image for project: 'Commons Net'
  1. Commons Net
  2. NET-602

Failure to parse times from SYST_L8 systems that report as "WINDOWS Type: L8"

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.3, 3.5
    • Fix Version/s: 3.6
    • Component/s: FTP
    • Labels:
      None
    • Environment:

      Windows Type: L8 FTP servers

      Description

      When getting file entries from a Type: L8 system running on a Windows server the code cannot extract the timestamp of the file correctly (it returns null).

      The entry format returned by the server is as follows:
      -rwxrwxrwx 1 user group 2490 Sep 7 2016 file.txt

      The reason for this appears to be a bug in the way the DefaultFTPFileEntryParserFactory constructs the CompositeFileEntryParser (createNTFTPEntryParser method), as when it passes the config object through to the NTFTPEntryParser first, the config passed through is updated with the Default timestamp format for Windows FTP servers "MM-dd-yy hh:mma", and then when the same config object is passed to the UnixFTPEntryParser it picks up this default and tries to use it instead of what it should be which is "MMM d yyyy".

      Not sure when this bug was introduced but it is at least present in 3.3 and 3.5.

      The problem may also be present for the createOS400FTPEntryParser, though I have not confirmed this.

      Potential Solution:
      When passing the config through to the parsers for each part of the CompositeFileEntryParser they should be using a clone of the original to avoid this kind of cross-contamination between different parser types.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              rossb Ross Braithwaite
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: