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

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)

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

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

Current code (FTPTimestampParserImpl r633380) does not work.

For example:

        FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
        DateFormat df = SimpleDateFormat.getDateTimeInstance();
        Calendar cal;
        cal=parser.parseTimestamp("feb 29 20:04");
        System.out.println(df.format(cal.getTime()));

generates

       01-Mar-2008 20:04:00

I think the code needs to add the year (current or +/- 1 year) to the string to be parsed.
I hope to provide a patch this weekend.

> 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, UnixParseLeapTest.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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

Rory Winston commented on NET-188:
----------------------------------

Hi Sebb

This works fine for me on net-1.5 and net-2.0. Can you step into the code and make sure that it is hitting the point where it adds the year element (which it should be doing already)?


> 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, UnixParseLeapTest.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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

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

Just found that the test works on Java 1.5 but fails with Java 1.4 (and probably 1.3)
Presumably something has changed in the Java 1.5 run-time library.

Since net 1.5 is targetted at Java 1.3 the problem needs to be fixed.

There also clearly need to be test cases for Feb 29.
I think full testing depends on NET-198 being applied, but one can run the following Feb 29 test at present:

{code}
    public void testParseFeb29() throws Exception {
        FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
        Calendar cal;
        cal=parser.parseTimestamp("feb 29 20:04");
        int dom = cal.get(Calendar.DAY_OF_MONTH);
        int mon = cal.get(Calendar.MONTH);
        if (dom != 29 || mon != Calendar.FEBRUARY){
            mon++;
            fail("failed to parse Feb 29; gave mon="+mon+" dom="+dom);
        }
    }
{code}

> 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, UnixParseLeapTest.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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

[hidden email] edited comment on NET-188 at 3/9/08 5:42 PM:
--------------------------------------------------

This is related to NET-83, which describes another instance where the FTP directory listing does not show the year.
Note that FreeBSD shows past and future dates without the year if the date is within 6 months of the current date, for example:

{code}
-rw-r--r--  1 user Domain Users  0 Sep  9  2007 200709091234.tmp
-rw-r--r--  1 user Domain Users  0 Sep 10 12:34 200709101234.tmp

-rw-r--r--  1 user Domain Users  0 Sep  7 12:34 200809071234.tmp
-rw-r--r--  1 user Domain Users  0 Sep  8  2008 200809081234.tmp

Sun Mar  9 15:05:09 EDT 2008 # date when listing was obtained
{code}

The file names show the actual timestamp used to "touch" the files.

Looks like the interval that is used is 26 weeks.
Provided that the client and server clocks are not adrift by more than a day, this should mean that a short date is never ambiguous.

      was (Author: [hidden email]):
    This is related to NET-83, which describes another instance where the FTP directory listing does not show the year.
Note that FreeBSD shows past and future dates without the year if the date is within 6 months of the current date, for example:

{code}
-rw-r--r--  1 user Domain Users  0 Sep  9  2007 200709091234.tmp
-rw-r--r--  1 user Domain Users  0 Sep 10 12:34 200709101234.tmp

-rw-r--r--  1 user Domain Users  0 Sep  7 12:34 200809071234.tmp
-rw-r--r--  1 user Domain Users  0 Sep  8  2008 200809081234.tmp

Sun Mar  9 15:05:09 EDT 2008 # date when listing was obtained
{code}

The file names show the actual timestamp used to "touch" the files.
 

> 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, UnixParseLeapTest.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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

Sebb updated NET-188:
---------------------

    Attachment: FTPTimestampParserLeap.patch

Patch which appears to solve the Feb 29 problem on Java 1.4.
Can also be applied to NET_2.0 branch if desired.
The patch changes the processing so the short form is always parsed with the current year appended.
So the short form format string(s) could potentially be changed to include the 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, FTPTimestampParserLeap.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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

Sebb updated NET-188:
---------------------

    Attachment:     (was: UnixParseLeapTest.patch)

> 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
>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

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

I applied the patch, and it works fine for Feb.29.

But I see a problem when it is Dec.31 on the client computer, server is in a different time zone and shows a date as Jan.01 -- in this case the result date is rolled back a whole year. Here is a test case, that can be added to FTPTimestampParserImplTest.java, and fails with both Commons.Net 1.4.1 as well as HEAD as well as with the patch applied:

    public void testParseJan01() throws Exception {
        GregorianCalendar now = new GregorianCalendar(2007, Calendar.DECEMBER, 31, 12, 0);
        checkShortParse("2007-12-31",now,now); // should always work
        GregorianCalendar target = (GregorianCalendar) now.clone();
        target.add(Calendar.DAY_OF_YEAR, +1);
        checkShortParse("2008-1-1",now,target);
    }


I think this is the kind of situation that was originally meant to address with the setLenienFutureDates() method - See NET-83, comment on FTPTimestampParserImpl is "Fix bug 35181 - add an option to specify leniency when needed because client and server systems cannot be synchronized."

The right solution, IMHO, is to allow short dates +- 6 months in the future or past, which seems to be in line with what FreeBSD is doing as well as what Linux is doing. Note that allowing a short date in the future might require adding "current year + 1" to the current Feb29 hack to fix a case where a future date is a leap year on Feb.29.

> 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
>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

Martin Oberhuber updated NET-188:
---------------------------------

    Attachment: jan01.patch

Patch to add testcase for Jan01 to FTPTimestampParserImplTest.java

Sorry for not knowing how to format the testcase properly in a Jira comment.

> 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

Rory Winston commented on NET-188:
----------------------------------

Ok, so if we add the +/- 6 month date parsing logic, do you think we should make this the default? Or an optional operating mode (like the current lenient mode)? Or could we just drop the lenient mode if we add the +/- 6 month parsing?

> 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

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
<code>
   FTPClientConfig#setShortDateRange(long msecPast, long msecFuture)
</code>
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() method.

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

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: 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

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

Mauricio Hiroshi Nagaoka commented on NET-188:
----------------------------------------------

Don't you guys think that the piece of code below:
                        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);
                        }
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:46 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{{monospaced}}if (lenientFutureDates) {
{{monospaced}} // add a day to "now" so that "slop" doesn't cause a date
{{monospaced}} // slightly in the future to roll back a full year.  (Bug 35181)
{{monospaced}} now.add(Calendar.DATE, 1);
{{monospaced}}}    
{{monospaced}}if (working.after(now)) {
{{monospaced}} working.add(Calendar.YEAR, -1);
{{monospaced}}}
 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:
                        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);
                        }
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:47 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{{monospaced}}
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);
}
{{monospaced}}
 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:
{{monospaced}}if (lenientFutureDates) {
{{monospaced}} // add a day to "now" so that "slop" doesn't cause a date
{{monospaced}} // slightly in the future to roll back a full year.  (Bug 35181)
{{monospaced}} now.add(Calendar.DATE, 1);
{{monospaced}}}    
{{monospaced}}if (working.after(now)) {
{{monospaced}} working.add(Calendar.YEAR, -1);
{{monospaced}}}
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:47 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{{
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);
}
}}
 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:
{{monospaced}}
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);
}
{{monospaced}}
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:47 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{{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);}}
{{}}}

 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:
{{
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);
}
}}
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:49 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{quote}
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);
}
{quote}
 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:
{{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);}}
{{}}}

 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:49 PM:
------------------------------------------------------------------------

Don't you guys think that the piece of code below:
{quote}
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);
\}
{quote}
 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:
{quote}
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);
}
{quote}
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:51 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:
{quote}
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);
\}
{quote}
 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:51 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.

Reply | Threaded
Open this post in threaded view
|

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

Jerome Wolff (Jira)
In reply to this post by Jerome Wolff (Jira)

    [ 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:52 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.

1234