commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: UnixFTPEntryParser - small fix (?)
Date Mon, 25 Aug 2003 22:29:53 GMT

In message <HJYO5I$>, "=?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
>  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

>  To correct that I changed line 85 of
>,  from version 1.0.1-dev, changing the
>section of regexp used to parse entries that concerns file's
>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 and for that listing format.
Many thanks for the suggestion!


View raw message