[
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)
