[net] NTFTPEntryParser parses directory names starting with a number followed by space incorrectly.

• Key: NET-63
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Sergey Smirnov
• Affects Version/s: 1.4

Environment

Operating System: All
Platform: All

Description

When I used FTPClient.listFiles() with MS FTP Server I found that directories with names starting with a
number followed by space being parsed incorrectly. But when I browse above-mentioned server with
Internet Explorer or with Total Commander’s built-in ftp client directory names are shown correctly.
Now look at the following failing test. (It should be added to NTFTPEntryParserTest class):

public void testDirectoryBeginningWithNumberFollowedBySpaces() throws Exception

{ FTPFile f = getParser().parseFTPEntry("12-03-96 06:38AM <DIR> 123 xyz"); assertEquals("name", "123 xyz", f.getName()); }

Junit output:
…
[junit] name expected:<123 ...> but was:<...>
[junit] junit.framework.ComparisonFailure: name expected:<123 ...> but was:<...>
…

The following patch fixes the problem:

Index: jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
===============================================================
====
RCS file: /home/cvspublic/jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/
NTFTPEntryParser.java,v
retrieving revision 1.19
diff -u -r1.19 NTFTPEntryParser.java
— jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
2 Jan 2005 03:17:50 -0000 1.19
+++ jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
13 Jun 2005 17:26:16 -0000
@@ -39,8 +39,7 @@
*/
private static final String REGEX =
"(\\S+)\\s+(\\S+)
s+"

• + "(<DIR>)?
  s*"
• + "([0-9]+)?
  s+"
  + + "(?<DIR>)|([0-9]+))
  s+"
  + "(
  S.*)";

/**

Comments

[Sergey Smirnov]

Created an attachment (id=15390)
The same patch is written in my bug report.

I’m sorry for inline patch in my bug report. It was first time when I used
bugzilla.

[Sergey Smirnov]

Created an attachment (id=15391)
Test to determine the bug.

[Steve Cohen]

I think your patch solves this problem (it correctly notes that we should expect
EITHER a <DIR> OR a number indicating size, not two optional fields) but I don't
think your patch goes far enough. I think we need to solve for the fact that
there can be spaces anywhere within an NT filename. 123 xyz works, but how
about 123 abc xyz?

[Steve Cohen]

(In reply to comment #3)
> I think your patch solves this problem (it correctly notes that we should expect
> EITHER a <DIR> OR a number indicating size, not two optional fields) but I don't
> think your patch goes far enough. I think we need to solve for the fact that
> there can be spaces anywhere within an NT filename. 123 xyz works, but how
> about 123 abc xyz?

By the way, excuse my manners. I should have thanked you for your patch.
You've found a real problem. The problem was just bigger than you thought it
was. If you feel like it, please submit another patch that solves for all the
names-with-spaces cases and includes tests for them in the Test class and then I
will commit it.

[Steve Cohen]

Actually, there was nothing at all wrong with your patch. The problem I had
thought existed did not, in fact, exist. I should have read the regular
expression more carefully.

I have committed your patch verbatim except that I added one more test assert to
prove that the scenario I had envisioned was not a problem. Thanks again for
your patch.

[Steve Cohen]

• • • COM-2655 has been marked as a duplicate of this bug. ***