You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Johannes Katelaan (JIRA)" <ji...@apache.org> on 2011/03/09 10:52:59 UTC

[jira] Created: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

FTPClient.listFiles() does not work properly, if remote server speaks German
----------------------------------------------------------------------------

                 Key: NET-365
                 URL: https://issues.apache.org/jira/browse/NET-365
             Project: Commons Net
          Issue Type: Bug
          Components: FTP
    Affects Versions: 2.2
            Reporter: Johannes Katelaan


If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.

You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.

The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:

{noformat}[a-zA-Z]{3}{noformat}

So the month name "Mär" will not match.

I fixed this by changing this part of REGEX to

{noformat}\\D{3}{noformat}

In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

Posted by "Sebb (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004480#comment-13004480 ] 

Sebb commented on NET-365:
--------------------------

I agree it's a bug, but I think \D is too wide a match, as it matches space/tab etc.

Might be better to use \p{isL} (is Unicode letter), but there are possibly other solutions.

Is there a public ftp server we can use to test this against?

> FTPClient.listFiles() does not work properly, if remote server speaks German
> ----------------------------------------------------------------------------
>
>                 Key: NET-365
>                 URL: https://issues.apache.org/jira/browse/NET-365
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>            Reporter: Johannes Katelaan
>
> If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.
> You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.
> The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:
> {noformat}[a-zA-Z]{3}{noformat}
> So the month name "Mär" will not match.
> I fixed this by changing this part of REGEX to
> {noformat}\\D{3}{noformat}
> In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

Posted by "Johannes Katelaan (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004524#comment-13004524 ] 

Johannes Katelaan commented on NET-365:
---------------------------------------

\p{IsL} works, too. Has to be a capital I.

> FTPClient.listFiles() does not work properly, if remote server speaks German
> ----------------------------------------------------------------------------
>
>                 Key: NET-365
>                 URL: https://issues.apache.org/jira/browse/NET-365
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>            Reporter: Johannes Katelaan
>
> If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.
> You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.
> The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:
> {noformat}[a-zA-Z]{3}{noformat}
> So the month name "Mär" will not match.
> I fixed this by changing this part of REGEX to
> {noformat}\\D{3}{noformat}
> In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb resolved NET-365.
----------------------

       Resolution: Fixed
    Fix Version/s: 3.0

In the end, decided to use \S{3}, because that is what most of the other parsers use.

> FTPClient.listFiles() does not work properly, if remote server speaks German
> ----------------------------------------------------------------------------
>
>                 Key: NET-365
>                 URL: https://issues.apache.org/jira/browse/NET-365
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>            Reporter: Johannes Katelaan
>             Fix For: 3.0
>
>
> If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.
> You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.
> The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:
> {noformat}[a-zA-Z]{3}{noformat}
> So the month name "Mär" will not match.
> I fixed this by changing this part of REGEX to
> {noformat}\\D{3}{noformat}
> In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

Posted by "Sebb (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004502#comment-13004502 ] 

Sebb commented on NET-365:
--------------------------

Can you try \p{isL} instead of \D and see if that works?

> FTPClient.listFiles() does not work properly, if remote server speaks German
> ----------------------------------------------------------------------------
>
>                 Key: NET-365
>                 URL: https://issues.apache.org/jira/browse/NET-365
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>            Reporter: Johannes Katelaan
>
> If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.
> You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.
> The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:
> {noformat}[a-zA-Z]{3}{noformat}
> So the month name "Mär" will not match.
> I fixed this by changing this part of REGEX to
> {noformat}\\D{3}{noformat}
> In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

Posted by "Johannes Katelaan (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004482#comment-13004482 ] 

Johannes Katelaan commented on NET-365:
---------------------------------------

Unfortunately this problem occurred with a private ftp server. The account we use is password protected and it's productive. So it cannot used for tests. I'm sorry.

> FTPClient.listFiles() does not work properly, if remote server speaks German
> ----------------------------------------------------------------------------
>
>                 Key: NET-365
>                 URL: https://issues.apache.org/jira/browse/NET-365
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>            Reporter: Johannes Katelaan
>
> If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.
> You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.
> The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:
> {noformat}[a-zA-Z]{3}{noformat}
> So the month name "Mär" will not match.
> I fixed this by changing this part of REGEX to
> {noformat}\\D{3}{noformat}
> In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-365) FTPClient.listFiles() does not work properly, if remote server speaks German

Posted by "Johannes Katelaan (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004522#comment-13004522 ] 

Johannes Katelaan commented on NET-365:
---------------------------------------

\p{isL} does not work - a
{noformat}
java.lang.IllegalArgumentException: Unparseable regex supplied
{noformat}
is thrown.

But \p{L} does the job.

> FTPClient.listFiles() does not work properly, if remote server speaks German
> ----------------------------------------------------------------------------
>
>                 Key: NET-365
>                 URL: https://issues.apache.org/jira/browse/NET-365
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>            Reporter: Johannes Katelaan
>
> If you are connecting to an FTP server that speaks German you will get German language month names in result to a LIST command. For month names with three-letter abreviations that are identical to the english versions (eg Jan) everything works fine. For month names that are not identical to the englisch versions (eg Dez instead of Dec) you will get FTPFile entrys without date/time information. This is just annoying, but OK.
> You get a real problem in March. The German abreviation is Mär, containing the German umlaut character ä. File entries with a date in March will just be dropped without further notice. I think this should be considered a bug.
> The reason for this behaviour is the REGEX in UnixFTPEntryParser, which matches only to month names containing "normal" letters:
> {noformat}[a-zA-Z]{3}{noformat}
> So the month name "Mär" will not match.
> I fixed this by changing this part of REGEX to
> {noformat}\\D{3}{noformat}
> In REGEX there are two occurances of the not working part that have to be changed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira