Steve,
Well done and good work with the latest changes that you have applied. I think
that we're getting to a 1.4 release stage very quickly.
Cheers
Rory
Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote:
Sorry for being a bit brusque before but if you check out the
Steve,
Well done and good work with the latest changes that you have applied. I think
that we're getting to a 1.4 release stage very quickly.
Cheers
Rory
Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote:
Sorry for being a bit brusque before but if you check out the
Rory Winston wrote:
Steve,
Well done and good work with the latest changes that you have applied. I think
that we're getting to a 1.4 release stage very quickly.
Cheers
Rory
With my latest work in bugzilla, I believe that we have no currently
open bugs. There were two. One was a duplicate of
AFAIK, the new system uses both: regexp for extracting the timestamp
from the entry line and then using DateFormat to parse that.
Example:
-rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp
from this line the regexp extracts the timestamp part (Jan 24 11:31)
and then DateFormat
Doesnt the client first need to extract the date string using a regex in order
to parse it using a [Simple]DateFormat?
Rory
_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit
I'm sorry, you're right again.
IWhen you first wrote me about the numeric date I assumed that the new
system just happened to handle it, without bothering to look at the
regex that decided what the date parser must parse. Then when I hadn't
heard from you for awhile, I thought we were over
ok, now I checked out the recent changes and the fix seems to work, at
least in the case of usual files:
-rw-r- 1 neeme neeme 346 2005-04-08 11:22 services.vsp
is parsed into:
typeStr=-
hardLinkCount=1
usr=neeme
grp=neeme
filesize=346
datestr=2005-04-08 11:22
However, I think if you attempt to take your good example and add it to
the JUnit tests, (as I just did) you will see that Rory's fix is not
sufficient. Yes, it correctly grabs the date string but it doesn't
parse it properly because the default UnixFTPEntryParser is still
assuming that a
I was incorrect again about the symbolic link thing being separate.
It's related to the two-part date.
Steve Cohen wrote:
However, I think if you attempt to take your good example and add it to
the JUnit tests, (as I just did) you will see that Rory's fix is not
sufficient. Yes, it correctly
Sorry for being a bit brusque before but if you check out the latest
code I think you will find that with Rory's and my changes, your issues
are cared for.
Neeme Praks wrote:
ok, now I checked out the recent changes and the fix seems to work, at
least in the case of usual files:
-rw-r- 1
Okay, we've solved the immediate issues here but I'm not totally
satisfied yet. The problem is that the numeric date format has
introduced a new logical possibility. Formerly it was simple and clear
- either with the default or recent date formats there were always THREE
whitespace-separated
Well, now I AM satisfied. I believe this is about as good as can be
done using regular expressions. I tried to do as little date format
validation as possible in the regex, but it is inevitable that some must
be done. The previous code prior to Neeme Praks' discoveries relied on
an
Ok, now I've found out what is the issue: the regexp pattern used by
UnixFTPEntryParser assumes too much about the format of the date. In
particular, it assumes that there are spaces inside the date or
something like that. As I'm not much of a regexp expert, I cannot really
pinpoint the
Right, the problem with this format is that the date is not composed of three
discrete components (from a regex POV), but two. Basically what we will need to
do is expand the regex to handle thuis - can you give me details of the FTP
server operating system and FTP server software version if
Right, the problem with this format is that the date is not composed of three
discrete components (from a regex POV), but two. Basically what we will need to
do is expand the regex to handle thuis - can you give me details of the FTP
server operating system and FTP server software version if
Neeme,
There is a preliminary (subject to review) fix in SVN for this problem.
For an example of how to parse this, look at:
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java?rev=161506view=markup
Cheers
Neeme,
There is a preliminary (subject to review) fix in SVN for this problem.
For an example of how to parse this, look at:
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java?rev=161506view=markup
Cheers
No, that's not it at all. Remember that the new system does not use
Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks'
descriptions, I am assuming he's now running the 1.3 or earlier
versions, which do use regexes.
This surprises me because I've had several conversations
It just refuses to list any files from the server.
Or is there some way to get more information about the possible issue?
I didn't see any logging statements in the code...
Rgds,
Neeme
Steve Cohen wrote:
I used the following configuration for parsing:
configuration defaultDateFormatStr=-MM-dd
OK.
There are no logging statements because jakarta-commons-net has no
dependencies on any particular logging package. Ant does.
I assume this configuration thing is a part of a custom task or
revised ftp task of your own design. That would be the place to put
in logging. You could even put
Steve Cohen wrote:
I assume this configuration thing is a part of a custom task or
revised ftp task of your own design. That would be the place to put
in logging. You could even put in the stack trace.
I already added some debug logging there, but this part seems to be
working just fine.
It
Neeme Praks wrote:
I now implemented support for FTPClientConfig in my local Ant ftp
task, but somehow it still fails to parse this directory listing,
although it parses the timestamp correctly (I tested that with jUnit).
Is it because the parser assumes that the 3rd and 4th parameters (owner
and
I now implemented support for FTPClientConfig in my local Ant ftp
task, but somehow it still fails to parse this directory listing,
although it parses the timestamp correctly (I tested that with jUnit).
Is it because the parser assumes that the 3rd and 4th parameters (owner
and group) are supposed
SOunds good. I do think if we go for 1.4 though, we should probably include
some of the smaller issues in BZ that would be easy to fix as well, and maybe
get some of those cleaned up. IIRC, most of the smaller bugs include patches or
source listings.
SOunds good. I do think if we go for 1.4 though, we should probably include
some of the smaller issues in BZ that would be easy to fix as well, and maybe
get some of those cleaned up. IIRC, most of the smaller bugs include patches or
source listings.
This format is from the default FTP server daemon configuration that
came with Debian:
Connected to stf.
220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
Name (stf:neeme): neeme
331 Password required for neeme.
Password:
230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686
Very good news that Debian is going to an all-numeric date format.
After mucking around in this mess for a couple of years, I often
wondered why standard unix ftp bothered with the abbreviations at all.
NT does not and does unix really want to take a back seat to NT in
matters such as this?
Rory Winston wrote:
SOunds good. I do think if we go for 1.4 though, we should probably include
some of the smaller issues in BZ that would be easy to fix as well, and maybe
get some of those cleaned up. IIRC, most of the smaller bugs include patches or
source listings.
I meant when you did the last release, of course.
Steve Cohen wrote:
Rory Winston wrote:
SOunds good. I do think if we go for 1.4 though, we should probably
include some of the smaller issues in BZ that would be easy to fix as
well, and maybe get some of those cleaned up. IIRC, most of the
The last release was from CVS. The docs were (are? - haven't checked) very
CVS-centric. I haven't attmepted to try a release from SVN yet, however I
presume it wouldn't be too arduous a task, given the ease of substitutability
between CVS/SVN. I fixed the issue with missing JUnit tests - they
4-6 weeks sounds reasonable.
Rory Winston wrote:
The last release was from CVS. The docs were (are? - haven't checked) very
CVS-centric. I haven't attmepted to try a release from SVN yet, however I
presume it wouldn't be too arduous a task, given the ease of substitutability
between CVS/SVN. I
Rory Winston writes:
As regards a timeline, I'm also pretty swamped over the next couple of weeks (
starting a new role, etc), so it will be tight for me until then. If I do get
a chance in the next couple of weeks I will look at fixing some of the more s
traightforward issues in BZ. It would be
Hi all!
Attached is a sample directory listing that breaks the 1.3.0 commons-net
FTP client directory parsing, at least when used from Ant task. The
basic difference is that the dates are specified as numbers (2005-03-21
14:26), not as month names.
I saw on the mailing list that there is now a
Wow! Thanks for showing us this.
That's a format I've not seen before. Where did it come from? Is it by
any chance a public site? In past experience, all unix ftp servers,
which I presume this to be, have used abbreviations for the months.
There IS a new system in the latest version of
Works for me. go for it.
Steve Cohen wrote:
Wow! Thanks for showing us this.
That's a format I've not seen before. Where did it come from? Is it by
any chance a public site? In past experience, all unix ftp servers,
which I presume this to be, have used abbreviations for the months.
There
35 matches
Mail list logo
