commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Oberhuber (JIRA)" <>
Subject [jira] Commented: (NET-188) FTPClient#listFiles returns null element when file's timestamp is "02/29"
Date Sun, 16 Mar 2008 20:53:24 GMT


Martin Oberhuber commented on NET-188:

I'd suggest that in terms of API, when a programmer knows the exact behavior of the server,
he should be able to get exact timestamps even if they are short and/or in the future. Right
now we know that FreeBSD does +-6-month short dates; Linux RHEL4 does +0/-6-month short dates.

So what about a new API like
   FTPClientConfig#setShortDateRange(long msecPast, long msecFuture)
that specifies in what range of time difference a short date is considered to be in the past,
or in the future respectively. The Javadoc comment could be similar to the #setLenientFutureDates()

The old setLenientFutureDates(boolean) method could be deprecated, and translated into this:
if(lenientFutureDates) {
   setShortDateRange(1000L * 86400 * 364, 1000L * 86400);
} else {
   setShortDateRange(1000L * 86400 * 365, 0);

I'm not completely sure what would be the best default value for the new settings. Given that
lenientFutureDates was false by default, we should probably always expect dates in the past
only by default. On the other hand, given that a "one day in future" date is much more likely
due to time zone differences than a "365 days in the past" short date, a setting of +1 day
/ -364 days might be a more appropriate default.

As a matter of fact, we cannot ever guarantee correct parsing when the user has not specified
by API what the setting should be. So the goal of a good default setting could either be "avoid
invalid dates even if a parse error occurs" (not expected by the average user, IMHO, as the
Feb.29 case shows); or, "always fall back to a reasonable date as it would be read by the
user, even if it might be incorrect".

Given that the original RFC for FTP says "The output of DIR is designed for human readers
and might not be machine readable", I think the default should be guided by what a human user
would expect from the listing. That being said, I think that when it's March 15 and I'm reading
"March 16" I'd expect a future date; reading "March 20" I'd expect a past date; so I'm in
favor of a "+1 day / -364 days" strategy by default.

Which is, admittedly, breaking the previous behavior which was lenientFuture == false meanding
a +0 / -365 strategy.

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>                 Key: NET-188
>                 URL:
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch,, FTPTimestampParserLeap.patch,
> This issue has same cause as VALIDATOR-221.
> throws ParseException
with timestampStr = "Feb 29 11:22".
> FTP Server status:
> {code}
> [root@localhost test-commonsnet]# pwd
> /tmp/test-commonsnet
> [root@localhost test-commonsnet]# ls -l
> total 0
> -rw-r--r--  1 root root 0 Dec 19  2006 aaa.txt
> -rw-r--r--  1 root root 0 Feb 29 11:22 bbb.txt
> {code}
> test code:
> {code}
> public void testCommonsNetLeapDay() throws Exception {
>     final FTPClient ftp = new FTPClient();
>     ftp.connect(host);
>     ftp.login(user, password);
>     final FTPFile[] listFiles = ftp.listFiles("/tmp/test-commonsnet");
>     for (int i = 0; i < listFiles.length; i++) {
>         System.out.println("[" + i + "] " + listFiles[i]);
>     }
>     ftp.disconnect();
> }
> {code}
> results bellow.
> {code}
> [0] -rw-r--r--    1 0        0               0 Dec 18  2006 aaa.txt
> [1] null
> {code}
> Second element(bbb.txt) should not be null.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message