[jira] Created: (NET-188) FTPClient#listFiles returns null element when file's timestamp is "02/29"

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581653#action_12581653 ]

mhnagaoka edited comment on NET-188 at 3/24/08 12:53 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{code}
if (lenientFutureDates) {
 // add a day to "now" so that "slop" doesn't cause a date
 // slightly in the future to roll back a full year.  (Bug 35181)
 now.add(Calendar.DATE, 1);
}    
if (working.after(now)) {
 working.add(Calendar.YEAR, -1);
}
{code}
 should also be executed when the {{hackFormatter}} is used? Rather than only when the {{recentDateFormat}} is used?

      was (Author: mhnagaoka):
    Don't you guys think that the piece of code below:
{code}
if (lenientFutureDates) {
 // add a day to "now" so that "slop" doesn't cause a date
 // slightly in the future to roll back a full year.  (Bug 35181)
 now.add(Calendar.DATE, 1);
}    
if (working.after(now)) {
 working.add(Calendar.YEAR, -1);
}
{code}
 should also be executed when the {hackFormatter} is used? Rather than only when the {recentDateFormat} is used?
 

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586215#action_12586215 ]

Sebb commented on NET-188:
--------------------------

Applied patch of 12/Mar/08 01:19 PM to trunk:


This fixes the Feb 29 test errors.

As far as I can see also addresses Mauricio's comment of 24/Mar/08.

There remains the problem of future dates.

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586215#action_12586215 ]

sebb@... edited comment on NET-188 at 4/6/08 5:29 PM:
--------------------------------------------------

Applied patch of 12/Mar/08 01:19 PM to trunk:

http://svn.apache.org/viewvc?rev=645336&view=rev

This fixes the Feb 29 test errors.

As far as I can see also addresses Mauricio's comment of 24/Mar/08.

There remains the problem of future dates.

      was (Author: sebb@...):
    Applied patch of 12/Mar/08 01:19 PM to trunk:


This fixes the Feb 29 test errors.

As far as I can see also addresses Mauricio's comment of 24/Mar/08.

There remains the problem of future dates.
 

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586219#action_12586219 ]

Sebb commented on NET-188:
--------------------------

I think the original bug (Feb 29 parsing) reported in this issue has now been solved, so this issue can be closed.

I've created two new JIRA issues to deal with the other issues raised in the discussion above:

NET-211 - setLenient() does not work across a year boundary
NET-212 - FTP short date parsing - how to handle future dates

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586394#action_12586394 ]

Martin Oberhuber commented on NET-188:
--------------------------------------

I'm also fine with closing this. There's only FTPTimestampParserImpl line 124 which I do not quite understand:

<code>
working.set(Calendar.YEAR, now.get(Calendar.YEAR));
</code>

This code branch only gets executed when the hackFormatter parsed OK, so it must have read the year already and setting the year yet again should be unnecessary?

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586402#action_12586402 ]

Sebb commented on NET-188:
--------------------------

I think you're correct - looks like that line is a left-over from the previous code, where the hackFormatter parsing was done later.

Fixed in:

http://svn.apache.org/viewvc?rev=645528&view=rev

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

     [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andre Sudhoff updated NET-188:
------------------------------

    Attachment: FTPTimestampParserImpl.patch

I've done another fix for the leap year problem. This should work regardless which is the correct year for the 29. Feb (this year or last year).

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserImpl.patch, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596445#action_12596445 ]

sumauan edited comment on NET-188 at 5/13/08 9:59 AM:
------------------------------------------------------------

I've done another fix for the leap year problem. This should work regardless which is the correct year for the 29. Feb (this year or last year).
See attached file "FTPTimestampParserImpl.patch"

Index: FTPTimestampParserImpl.java
===================================================================
--- FTPTimestampParserImpl.java (revision 473)
+++ FTPTimestampParserImpl.java (working copy)
@@ -41,6 +41,7 @@
 
  private SimpleDateFormat defaultDateFormat;
  private SimpleDateFormat recentDateFormat;
+ private SimpleDateFormat recentWithYearDateFormat;
 
 
  /**
@@ -75,35 +76,62 @@
  ParsePosition pp = new ParsePosition(0);
 
  Date parsed = null;
- if (this.recentDateFormat != null) {
- parsed = recentDateFormat.parse(timestampStr, pp);
- }
- if (parsed != null && pp.getIndex() == timestampStr.length())
- {
- working.setTime(parsed);
- working.set(Calendar.YEAR, now.get(Calendar.YEAR));
- if (working.after(now)) {
- working.add(Calendar.YEAR, -1);
- }
- } else {
+ if (recentWithYearDateFormat != null) {
+ //For the 29. Feb of a leap year we have to parse with the correct year because
+ //parsing without a year defaults to 1970 which is not a leap year, then the parsing fails or we get the 1 of mrach
+ String timestamWithYearStr = timestampStr.trim() + " " + now.get(Calendar.YEAR);
  pp = new ParsePosition(0);
- parsed = defaultDateFormat.parse(timestampStr, pp);
- // note, length checks are mandatory for us since
- // SimpleDateFormat methods will succeed if less than
- // full string is matched.  They will also accept,
- // despite "leniency" setting, a two-digit number as
- // a valid year (e.g. 22:04 will parse as 22 A.D.)
- // so could mistakenly confuse an hour with a year,
- // if we don't insist on full length parsing.
- if (parsed != null && pp.getIndex() == timestampStr.length()) {
+ parsed = recentWithYearDateFormat.parse(timestamWithYearStr, pp);
+ if (parsed != null && pp.getIndex() == timestamWithYearStr.length()) {
  working.setTime(parsed);
+ working.set(Calendar.YEAR, now.get(Calendar.YEAR));
+ if (working.after(now)) {
+ working.add(Calendar.YEAR, -1);
+ }
+
+ return working;
  } else {
- throw new ParseException(
- "Timestamp could not be parsed with older or recent DateFormat",
- pp.getIndex());
+ timestamWithYearStr = timestampStr.trim() + " " + (now.get(Calendar.YEAR) - 1);
+ pp = new ParsePosition(0);
+ parsed = recentWithYearDateFormat.parse(timestamWithYearStr, pp);
+ if (parsed != null && pp.getIndex() == timestamWithYearStr.length()) {
+ working.setTime(parsed);
+ return working;
+ }
  }
+ } else if (this.recentDateFormat != null) {
+ parsed = recentDateFormat.parse(timestampStr, pp);
+ if (parsed != null && pp.getIndex() == timestampStr.length())
+ {
+ working.setTime(parsed);
+ working.set(Calendar.YEAR, now.get(Calendar.YEAR));
+ if (working.after(now)) {
+ working.add(Calendar.YEAR, -1);
+ }
+
+ return working;
+ }
  }
- return working;
+
+ pp = new ParsePosition(0);
+ parsed = defaultDateFormat.parse(timestampStr, pp);
+ // note, length checks are mandatory for us since
+ // SimpleDateFormat methods will succeed if less than
+ // full string is matched.  They will also accept,
+ // despite "leniency" setting, a two-digit number as
+ // a valid year (e.g. 22:04 will parse as 22 A.D.)
+ // so could mistakenly confuse an hour with a year,
+ // if we don't insist on full length parsing.
+ if (parsed != null && pp.getIndex() == timestampStr.length()) {
+ working.setTime(parsed);
+
+ return working;
+ }
+
+
+ throw new ParseException(
+ "Timestamp could not be parsed with older or recent DateFormat",
+ pp.getIndex());
  }
 
  /**
@@ -146,6 +174,11 @@
  if (format != null) {
  this.recentDateFormat = new SimpleDateFormat(format);
  this.recentDateFormat.setLenient(false);
+
+ if (format.indexOf("y") == -1) {
+ this.recentWithYearDateFormat = new SimpleDateFormat(format.trim() + " yyyy");
+ this.recentWithYearDateFormat.setLenient(false);
+ }
  }
  }
 
@@ -179,6 +212,9 @@
  if (this.recentDateFormat != null) {
  this.recentDateFormat.setTimeZone(serverTimeZone);
  }
+ if (this.recentWithYearDateFormat != null) {
+ this.recentWithYearDateFormat.setTimeZone(serverTimeZone);
+ }
  }
 
  /**
@@ -223,6 +259,11 @@
  } else {
  this.recentDateFormat = new SimpleDateFormat(recentFormatString, dfs);
  this.recentDateFormat.setLenient(false);
+
+ if (recentFormatString.indexOf("y") == -1) {
+ this.recentWithYearDateFormat = new SimpleDateFormat(recentFormatString.trim() + " yyyy", dfs);
+ this.recentWithYearDateFormat.setLenient(false);
+ }
  }
 
  String defaultFormatString = config.getDefaultDateFormatStr();



      was (Author: sumauan):
    I've done another fix for the leap year problem. This should work regardless which is the correct year for the 29. Feb (this year or last year).
 

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserImpl.patch, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596452#action_12596452 ]

Sebb commented on NET-188:
--------------------------

Thanks, but it has already been fixed in SVN.

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserImpl.patch, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

    [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597281#action_12597281 ]

Antonio Gallardo commented on NET-188:
--------------------------------------

If this is fixed, you should close this issue. :)

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserImpl.patch, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.

     [ https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rory Winston closed NET-188.
----------------------------

       Resolution: Fixed
    Fix Version/s: 2.0
                   1.5

> FTPClient#listFiles returns null element when file's timestamp is "02/29"
> -------------------------------------------------------------------------
>
>                 Key: NET-188
>                 URL: https://issues.apache.org/jira/browse/NET-188
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: HONMA Hirotaka
>             Fix For: 1.5, 2.0
>
>         Attachments: commons-net-ftp-date-parser-feb29.patch, DstParseTest.java, FTPTimestampParserImpl.patch, FTPTimestampParserLeap.patch, jan01.patch
>
>
> This issue has same cause as VALIDATOR-221.
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp 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.