Allow FTPFile entries to be generated even if date parsing fails

• Key: NET-205
• Type: Improvement
• Status: Reopened
• Priority: Major
• Assignee: Unassigned
• Reporter: Sebb

Description

Most of the FTPEntryParser classes return null if date parsing fails.

This can cause an otherwise good entry to be ignored, when perhaps the only problem is that the parsing is faulty.

The suggestion is to allow such entries to be kept, but with a null date.

This is already done by the EnterpriseUnixFTPEntryParser.

Patches to follow.

Comments

[Sebb]

Patch to allow unparseable dates.

Also fixes test suite to check for null date as well as null entry when checking for failures.

[Martin Oberhuber]

I've observed one problem with this change, that a totally wrong FTP parser now easily produces invalid entries when the text that should be a date isn't even remotely a date.

For instance, parsing output of a VMS server with the NTFTPEntryParser, results in this text being parsed as follows:

Total of 5 files, 470/606 blocks

--> datestr = "Total of"
--> size = 5
--> name = "files, 470/606 blocks"

Attached patch gives up when the time parser doesn't even get past the first 4 characters - not sure if that's a good idea, but at least it is closer to what Commons Net was like in previous releases.

[Sebb]

Not entirely sure this is needed, given that the problem only occurs if the wrong parser is used.

However, assuming that it does make sense to protect against using the wrong parser, then perhaps this check - or something like it - should be applied to any of the other parsers?