You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ross Braithwaite (JIRA)" <ji...@apache.org> on 2016/09/09 02:33:20 UTC

[jira] [Created] (NET-602) Failure to parse times from SYST_L8 systems that report as "WINDOWS Type: L8"

Ross Braithwaite created NET-602:
------------------------------------

             Summary: Failure to parse times from SYST_L8 systems that report as "WINDOWS Type: L8"
                 Key: NET-602
                 URL: https://issues.apache.org/jira/browse/NET-602
             Project: Commons Net
          Issue Type: Bug
          Components: FTP
    Affects Versions: 3.5, 3.3
         Environment: Windows Type: L8 FTP servers
            Reporter: Ross Braithwaite


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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)