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)