[net] Re: UnixFTPEntryParser - small fix (?)

[Matthieu Recouly <ma...@laposte.net>]

Hi, I'm posting this message here on demand from Daniel who is
very busy for the moment



From    : "Matthieu Recouly" <ma...@laposte.net>
To      : "dfs" <df...@savarese.org>
Date    : Tue, 26 Aug 2003 10:12:44 +0200
Subject : Re: UnixFTPEntryParser - small fix (?)


Hi :)


First many thanks for having taken my message in consideration ;).

You are right by saying that I require 2 spaces to be present
between user and size (or date, or whatever the next field is).
In fact my "solution" is really for users without group, here
is the directory listing I get if I call "ls -la" command on
the FTP server I deal with:

ftp> ls -la
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 122310
drwxr-xr-x   2 0        other        512 Oct 15  2002 .
dr-xr-xr-x   3 0        other        512 Oct 24  2002 ..
-rw-r-----  13 XML      fullxml  32378426 Aug 25 23:00
nxmlfeed.xml
-rw-r--r--   2 0        other          8 Apr 25  2002 text.txt
-rw-r-----   4 XML      fullxml  27669955 Oct 14  2002 xmlfeed.xml
-rw-r-----   4 XML      fullxml  2506213 Oct 14  2002
xmlincremental.xml
226 Transfer complete.


You will notice that there are actually two spaces between
"user" and size, this because I think group is really omitted
or inexistent, and not appended to user as an error.

Anyway your solution does work and will indeed handle cases
where group is also happened to user, so thank you for having
thought about it :).


Another thing I would like to discuss is on the same server I
often have my transfers stuck when sending "completion
command" when transfer is over.

With small investigation, I arrived to conclusion that method
"__getReply()" in class "FTP" will sometimes block on
instruction "String line = _controlInput.readLine();" (cannot
give the source code line, sorry).

One important think is I'm using jdk1.3.1, so maybe the
BufferedReader used as "_controlInput" has a problem but I
really doubt of that.
What I did is changing from "readLine()" to "read()" within a
loop in order to see what was exactly received by the client.
I used this opportunity to add a "time out" when buffered
reader has not been marked "ready" for more than 20 sec.

It happens that what is received by client is exactly what is
expected: a string terminated with a character of which code
is 10: the '\n ' char.
So I really don't understand with "readLine()" is sometimes
stuck with this... any idea ? :/

(note: with my small loop + time out my transfers never block,
maybe an internal timeout check should be added in this method ?)


Thank you for your time.


Matthieu.


---------- initial message -----------

From     : "Daniel F. Savarese" <df...@savarese.org>
To       : commons-dev@jakarta.apache.org
Copies   : matthieu.recouly@laposte.net
Date     : Mon, 25 Aug 2003 18:29:53 -0400
Subject  : Re: UnixFTPEntryParser - small fix (?)


In message
<HJ...@laposte.net>,
"=?iso-8859-1
?Q?Matthieu_Recouly?=" writes:
> Your parser does not allow to retrieve files list on a ftp
>server that uses "weird Unix listing style" as described on
>http://www.javaworld.com/javaworld/jw-04-2003/jw-0404-ftp-p2.html
> 
>  This is when user has no group, your parser will put the
>size value inside group's one, a null user value, and 0 in the
>size field.

I think what happens is that the FTP server ends up omitting a
space
between the user and group in the listing, although it's certainly
possible some FTP servers out there forgo listing the group
altogether.  Regardless, it's the same effect: one less
space-separated
field.

>  To correct that I changed line 85 of
>UnixFTPEntryParser.java,  from version 1.0.1-dev, changing the
>section of regexp used to parse entries that concerns file's
>group:
>
>changed "+ "(\\S+)\\s+" to "+ "(\\S+)?\\s+" (added question mark)

I think there's a problem with the change as proposed because when
combined with the previous expression that matches the user, you
wind up mandating at least two spaces before the date instead of
one.  Alternatives are to change the user expression to
"(\\S+)\\s*"
and the group to what you suggest, but for the sake of clarity I
recommend using the following for the group pattern
"(?:(\\S+)\\s+)?".
Also, I believe EnterpriseUnixFTPEntryParser handles the listing
format just fine.

In any case, I applied the change using my variation of the
pattern
and added test cases to UnixFTPEntryParser.java and
EnterpriseUnixFTPEntryParser.java for that listing format.
Many thanks for the suggestion!

daniel

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)