UnixDirectoryListingFormatter Causing Incorrect Last Modified Date

[pbtura]

When looking at the results of an FTPClient.listFiles() call, the returned FTPFile objects are missing data from the lastModified timestamp. Date information (year, month, day) is correct but all other field are null or default. I did some debugging and the source of the issue seems to be the UnixDirectoryListingFormatter class. The date formatter being used is private static final String DATE_FORMAT = "MMM dd yyyy"; which is causing data to be lost when converting the file system information into a response string for the FTP command.

Is there some reason for using this particular format? Would it be possible to add a configuration option to allow the user to specify a date format when setting up the file system?

Step to Reproduce:

1. Create a FakeFtpServer and add a UnixFakeFileSystem.
2. Create a new File and add it to the file system taking note of the date and time.
3. Use an FTP client to connect to the FakeFtpServer.
4. Execute a 'listFiles' command on the directory where the file was added.
5. Call getTimeStamp() on one or more of the returned FTPFile objects. The result will be missing all date information other than year, month, and day.

[chrismair]

That original implementation was a simplifying assumption. As I understand it, "MMM DD YYYY " is one of the two valid formats, and the other is "MMM DD hh:mm", if the date is "recent", e.g. within the last six months.

So its not like you'd ever be guaranteed to get the time portion from your "real" FTP server, unless you know the date is recent, and even that could be system-dependent.

Just out of curiosity, what is this breaking for you?

[pbtura]

I had an application where I needed to filter the files in an FTP directory by date. Since the UnixDirectoryListingFormatter only includes the MMM DD YYYY format, my tests on recently created files were breaking. I eventually managed to find a workaround by creating my own implementation of DirectoryListingFormatter and applying it to the test FileSystem during test setup. It wasn't that difficult once I understood exactly what was going on.

At the very least, this is probably something worth calling out in the documentation. Knowing why the getTimestamp() call was returning a different value from what I expected and what the potential options were would have saved a lot of digging through the source code.

Even better would be to handle both date formats in the implementations of DirectoryListingFormatter. The implementation I went with simply compares the year of the lastModified date of the fileSystemEntry against the current date and selects the date format based on the result.

[chrismair]

Fixed for MockFtpServer 3.0.0