commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (NET-602) Failure to parse times from SYST_L8 systems that report as "WINDOWS Type: L8"
Date Tue, 07 Feb 2017 23:24:41 GMT

     [ https://issues.apache.org/jira/browse/NET-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sebb resolved NET-602.
----------------------
       Resolution: Fixed
    Fix Version/s: 3.6

URL: http://svn.apache.org/viewvc?rev=1782089&view=rev
Log:
NET-602 Failure to parse times from SYST_L8 systems that report as "WINDOWS Type: L8"

Modified:
    commons/proper/net/trunk/src/changes/changes.xml
    commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClientConfig.java
    commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java


> 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.3, 3.5
>         Environment: Windows Type: L8 FTP servers
>            Reporter: Ross Braithwaite
>             Fix For: 3.6
>
>
> 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.15#6346)

Mime
View raw message