You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Rory Winston (JIRA)" <ji...@apache.org> on 2008/03/01 13:08:51 UTC

[jira] Closed: (NET-190) [FTP Client] Not listing files with 'invalid' date

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

Rory Winston closed NET-190.
----------------------------

    Resolution: Duplicate

> [FTP Client] Not listing files with 'invalid' date
> --------------------------------------------------
>
>                 Key: NET-190
>                 URL: https://issues.apache.org/jira/browse/NET-190
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: FTP Gateway: Response:	331-httpiproxy2 FTP server (Version 1.9.2.4 - 2005/01/11 13:03:28) ready.
> FTP Server: Response:	215 UNIX Type: L8
> FTP Client: Jakarta Commons VFS over Jakarta Commons NET
>            Reporter: Diego Souto
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> When trying to list files in a FTP directory with two files returns 0 FileObjects.
> With another FTP client.... response is:
> ftp> ls
> 227 Entering Passive Mode (212,163,35,155,160,40)
> 150 Conexión de datos aceptada
> -rw-r--r--    1 0        0             222 Feb 29 09:47 AYC01R
> -rw-r--r--    1 0        0             688 Feb 29 03:04 AYC02R
> 226-Options: -l 
> 226 2 ocurrencias en total
> ... so there are two files with date "FEBRUARY 29" (2008 is a leap year)
> When listing files with Jakarta Commons VFS over Jakarta Commons NET it returns 0 files.
> I revised Commons Net source and I found in 'org.apache.commons.net.ftp.parser.UnixFTPEntryParser' the following code:
>             try
>             {
>                 file.setTimestamp(super.parseTimestamp(datestr));
>             }
>             catch (ParseException e)
>             {
>             	return null;  // this is a parsing failure too.
>             }
> So I guess maybe the timestamp parser is throwing a ParseException (perhaps it's guessing a incorrect year) and in this case is returning NULL so the calling class is ignoring these files with 'Feb 29' date.
> I think this behaviour is incorrect and must be fixed. If date is considered invalid it would throw an exception,... not simply ignore the file.

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