You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2008/03/10 03:58:28 UTC
[NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
I've committed updates to the FTPTimestampParserImplTest classes in
trunk and NET_2_0.
The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) now fail on short
dates that fall in a different year from current (previous or next).
Some of the existing tests assume that dates cannot be more than 1
hour in the future - IMO this is wrong - so I propose to drop these
tests.
I'm working on a patch which I'll add as a patch to NET-188.
On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> Sure, you can just add them directly yourself if you like.
>
> Rory
>
>
> The *nix short date formatting fixes don't currently have any tests,
> at least when I last checked.
>
> I think these need to be added first.
>
> I can add some later today if that's OK with you?
> Or do you want them done as patches via Jira?
>
>
> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> > Hi James
> >
> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
> >
> > Thanks
> >
> > Rory
> >
> >
> >
> > James Carman wrote:
> > > On 3/8/08, Rory Winston <ro...@gmail.com> wrote:
> > >
> > >> I've taken into account the suggestions proposed by various people wrt
> > >> the TFTP server classes and accordingly made some changes. Thanks for
> > >> the feedback.
> > >>
> > >>
> > >
> > > So, does that mean you're cutting (or have already done so) a new
> > > release candidate for us to vote on?
> > >
> > >
> > >> Rory
> > >>
> > >>
> > >> sebb wrote:
> > >> > On 07/03/2008, Henri Yandell <fl...@gmail.com> wrote:
> > >> >
> > >> >> On Fri, Mar 7, 2008 at 8:04 AM, James Carman <ja...@carmanconsulting.com> wrote:
> > >> >> > On 3/2/08, Rory Winston <ro...@gmail.com> wrote:
> > >> >> > > Hi
> > >> >> > >
> > >> >> > > This is a release vote for Commons Net 1.5. This release fixes a few
> > >> >> > > issues with TFTP errors, threading hangs, and a leap year date parsing bug.
> > >> >> > >
> > >> >> > > The RC deployment is here:
> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/site/
> > >> >> > >
> > >> >> > > Binaries:
> > >> >> > >
> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/commons-net-1.5.0-SNAPSHOT-bin.zip
> > >> >> > >
> > >> >> > > Source:
> > >> >> > >
> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/commons-net-1.5.0-SNAPSHOT-src.tar.gz
> > >> >> > >
> > >> >> > > Javadocs:
> > >> >> > >
> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/site/apidocs/index.html
> > >> >> > >
> > >> >> > > SVN tag:
> > >> >> > >
> > >> >> > > http://svn.apache.org/viewvc/commons/proper/net/tags/NET_1_5_0/
> > >> >> > >
> > >> >> > > Here's my +1 in advance.
> > >> >> > > Cheers
> > >> >> > > Rory
> > >> >> > >
> > >> >> >
> > >> >> > I just wanted to post my official -1 vote. I feel that the
> > >> >> > org.apache.commons.net.tftp.TFTPServer class is outside the scope of
> > >> >> > Commons Net. I have no problem with it being in the test classes, as
> > >> >> > suggested, though.
> > >> >>
> > >> >>
> > >> >> Not a problem for me. +1 to including the server class.
> > >> >>
> > >> >> It's not big codewise, and is not that far from Net's scope or Commons scope.
> > >> >>
> > >> >
> > >> > But it's not in scope (yet?)
> > >> >
> > >> >
> > >> >> Two proviso's:
> > >> >>
> > >> >> 1) The main method in TFTPServer should be removed.
> > >> >>
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> >> 2) If we get lots of embedded server components, then we should
> > >> >> rethink this, but I can see that the 'simple embedded server space' is
> > >> >> pretty small. Might want to use a different package to allow it to
> > >> >> more easily be split out. org.apache.commons.net.server.* or
> > >> >> something. Then people can send in their dumb EchoServer
> > >> >> implementations :)
> > >> >>
> > >> >
> > >> > +1 to changing package name.
> > >> >
> > >> > I still think it should be in the test tree; AFAICS the purpose of the
> > >> > code contribution was to enable the TFTP Client to be tested.
> > >> >
> > >> > If Commons starts getting other simple server implementations then
> > >> > these ought to be part of a different project with a scope of
> > >> > Testing/Mocking or some such. Maybe not even in Commons.
> > >> >
> > >> >
> > >> >> Hen
> > >> >>
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Posted by sebb <se...@gmail.com>.
On 11/03/2008, Rory Winston <ro...@gmail.com> wrote:
> Sebb/Martin
Martin and I agree on wanting the parser to return an FTPFile rather
than null for the cases where the date (etc ?) does not parse OK. I
would like to see this go into the next release of NET 1.5 and 2.0; I
think this will avoid a lot of future problems.
Martin has yet to express an opinion about the +/- 6 month issue, as
far as I know.
> The lenient future dates flag just allows a window of +1 day in the
> short timestamp, which if > now(), will not be rolled back by a year.
But why should they be rolled back by a year?
Is it documented behaviour in any FTP implementations that dates in
the past year are displayed without the year? If so, which
implementations?
> This is to prevent dates slightly in the future being rolled back
> inappropriately.
That much I agree with.
> You keep mentioning the +/- 6 month thing - the problem
> is that this (like a lot of other FTP stuff) isn't a standard and you
> can't depend on it.
It does seem to be true for at least some *nix systems, and "man ls"
(which is where FTP seems to take its lead) specifically describes
this behaviour. I've tried it on FreeBSD, and FTP does behave this way
there. I hope to try it on HP-UX and Ubuntu soon.
> Still, there are a bunch of other flags in there to
> work around other issues, so maybe another flag might be required for
> fully comprehensive date handling.
>
> Say if we have a date d ( 1 day < d <= 6 months) in the future, this
> flag would control whether d is rolled back (as it would be now) or kept
> in the current year (which we would need a flag for).
Not necessarily the current year - it could be the next year if the
current date is in the second half of the year.
> Is this what is needed to get the remaining tests to pass?
Yes - but as I wrote in a previous e-mail, this could be left for
later if required.
It should not often happen.
What is vital for the release of 1.5 is fixing the Feb 29 problem.
> Rory
>
> sebb wrote:
> > On 10/03/2008, sebb <se...@gmail.com> wrote:
> >
> >> On 10/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > Hi Sebb
> >> >
> >> > A couple of things:
> >> >
> >> > 1. Which tests are you referring to in your first point below?
> >>
> >>
> >> testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
> >> testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
> >>
> >> The first one only applies in leap years - it was designed before the
> >> addition of the server calendar parameter. It could perhaps be
> >> dropped.
> >>
> >> I've since fixed the following test, and it also fails, but only on 1.4:
> >>
> >> testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
> >>
> >>
> >> > 2. Does the assumption have anything to do with the lenientFutureDates
> >> > flag in FTPTimestampParserImpl?
> >> >
> >>
> >>
> >> Yes, the *nix future dates thing is tied in with lenientFutureDates.
> >>
> >> I suspect there may need to be a new flag which enables *nix style +/-
> >> 6 months dates.
> >>
> >> I don't understand what the lenient flag is about - was it part of an
> >> attempt to handle *nix dates (in which case it's wrong, as lenient
> >> allows up to 1 year in arrears), or is it for different OSes?
> >>
> >> The past and future date tests need extending as well; there should be
> >> one test where the current date is in the first 6 months of the year,
> >> and another where it is in the second 6 months of the year (and
> >> perhaps leap/non-leap years too).
> >>
> >>
> >
> > The past and future tests have been updated as above.
> >
> > The future tests fail on both trunk and 2.0.
> > However, the cases where they apply are relatively rare, so fixing
> > them could be left until a later release.
> >
> > The Feb 29 failures definitely need to be fixed before trunk is released.
> >
> > It seems to me that there will probably still be some valid edge cases
> > where the date validation fails. AIUI at present this would mean that
> > the entire entry is set to null.
> >
> > Seems to me it would be a lot better if the FTPFile entry was still
> > generated, but with a null date.
> >
> > Not all users need the dates, so this would allow Net to fail more gracefully.
> >
> >
> >> > Rory
> >> >
> >> >
> >> > sebb wrote:
> >> > > I've committed updates to the FTPTimestampParserImplTest classes in
> >> > > trunk and NET_2_0.
> >> > >
> >> > > The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
> >> > >
> >> > > Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) now fail on short
> >> > > dates that fall in a different year from current (previous or next).
> >> > >
> >> > > Some of the existing tests assume that dates cannot be more than 1
> >> > > hour in the future - IMO this is wrong - so I propose to drop these
> >> > > tests.
> >> > >
> >> > > I'm working on a patch which I'll add as a patch to NET-188.
> >> > >
> >> > > On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > >
> >> > >> Sure, you can just add them directly yourself if you like.
> >> > >>
> >> > >> Rory
> >> > >>
> >> > >>
> >> > >> The *nix short date formatting fixes don't currently have any tests,
> >> > >> at least when I last checked.
> >> > >>
> >> > >> I think these need to be added first.
> >> > >>
> >> > >> I can add some later today if that's OK with you?
> >> > >> Or do you want them done as patches via Jira?
> >> > >>
> >> > >>
> >> > >> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > >> > Hi James
> >> > >> >
> >> > >> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
> >> > >> >
> >> > >> > Thanks
> >> > >> >
> >> > >> > Rory
> >> > >> >
> >> > >> >
> >>
> >>
> >> <snip/>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
Hi all,
regarding FTP parser date +-6 month problem:
Having a look at
http://www.ietf.org/rfc/rfc3659.txt?number=3659 section 3
it seems that there is a standardization effort in place
to finally get time values right for FTP (proposed standard
"MDTM" command. So this is what we'll want to have in the
future to get 100% correct dates. And this is what clients
could potentially use if a server supports it and the
normal ftp parser returns a "null" date due to parsing
problems.
Check availability of this feature on the server with:
ftp> literal syst
215 UNIX Type: L8
ftp> literal feat
211-Features:
EPRT
EPSV
MDTM
PASV
REST STREAM
SIZE
TVFS
211 End
ftp>
Also, there will be MLST and MLSD for machine listing to
get rid of the problems with LIST / DIR commands (see
section 7 of RFC3659).
That being said, my point is that if a server doesn't support
the MDTM command and the LS output of "dir" is ambiguous,
there is not much point in guessing and doing it one way or
the other. I really don't care much about whether dates upto
6 months in the future are returned as future or back, though
I have a slight preference for not dealing with future dates
too much since they are a corner case. One day in the future
is fine since it can happen due to time zone differences, but
not more. Who would consciously create a file in the future?
If in doubt, the MDTM command is the way to go for disambiguating.
And the FTPClient should not send the command itself but allow
the client to send it, if client thinks that exact times are
required.
About anything else in the DIR output, the FTP standard says:
http://www.ietf.org/rfc/rfc0959.txt?number=959
LIST: "Since the information on a file may vary widely from system
to system, this information may be hard to use automatically
in a program, but may be quite useful to a human user."
So summing up: I'm in favor of only allowing 1-day-in-the-future
dates and rolling back all others; but I really don't care a lot
since the way to go is standardized commands for machine processing.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Rory Winston [mailto:rory.winston@gmail.com]
> Sent: Dienstag, 11. März 2008 21:10
> To: Jakarta Commons Developers List
> Subject: Re: [NET] fixing short date parsing problems (was:
> [VOTE] Release Commons Net 1.5)
>
> Sebb/Martin
>
> The lenient future dates flag just allows a window of +1 day in the
> short timestamp, which if > now(), will not be rolled back by a year.
> This is to prevent dates slightly in the future being rolled back
> inappropriately. You keep mentioning the +/- 6 month thing -
> the problem
> is that this (like a lot of other FTP stuff) isn't a standard and you
> can't depend on it. Still, there are a bunch of other flags
> in there to
> work around other issues, so maybe another flag might be required for
> fully comprehensive date handling.
>
> Say if we have a date d ( 1 day < d <= 6 months) in the future, this
> flag would control whether d is rolled back (as it would be
> now) or kept
> in the current year (which we would need a flag for).
>
> Is this what is needed to get the remaining tests to pass?
>
> Rory
>
> sebb wrote:
> > On 10/03/2008, sebb <se...@gmail.com> wrote:
> >
> >> On 10/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > Hi Sebb
> >> >
> >> > A couple of things:
> >> >
> >> > 1. Which tests are you referring to in your first point below?
> >>
> >>
> >>
> testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimes
> tampParserImplTest)
> >>
> testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimesta
> mpParserImplTest)
> >>
> >> The first one only applies in leap years - it was
> designed before the
> >> addition of the server calendar parameter. It could perhaps be
> >> dropped.
> >>
> >> I've since fixed the following test, and it also fails,
> but only on 1.4:
> >>
> >>
> testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTime
> stampParserImplTest)
> >>
> >>
> >> > 2. Does the assumption have anything to do with the
> lenientFutureDates
> >> > flag in FTPTimestampParserImpl?
> >> >
> >>
> >>
> >> Yes, the *nix future dates thing is tied in with
> lenientFutureDates.
> >>
> >> I suspect there may need to be a new flag which enables
> *nix style +/-
> >> 6 months dates.
> >>
> >> I don't understand what the lenient flag is about - was
> it part of an
> >> attempt to handle *nix dates (in which case it's wrong, as lenient
> >> allows up to 1 year in arrears), or is it for different OSes?
> >>
> >> The past and future date tests need extending as well;
> there should be
> >> one test where the current date is in the first 6 months
> of the year,
> >> and another where it is in the second 6 months of the year (and
> >> perhaps leap/non-leap years too).
> >>
> >>
> >
> > The past and future tests have been updated as above.
> >
> > The future tests fail on both trunk and 2.0.
> > However, the cases where they apply are relatively rare, so fixing
> > them could be left until a later release.
> >
> > The Feb 29 failures definitely need to be fixed before
> trunk is released.
> >
> > It seems to me that there will probably still be some valid
> edge cases
> > where the date validation fails. AIUI at present this would
> mean that
> > the entire entry is set to null.
> >
> > Seems to me it would be a lot better if the FTPFile entry was still
> > generated, but with a null date.
> >
> > Not all users need the dates, so this would allow Net to
> fail more gracefully.
> >
> >
> >> > Rory
> >> >
> >> >
> >> > sebb wrote:
> >> > > I've committed updates to the
> FTPTimestampParserImplTest classes in
> >> > > trunk and NET_2_0.
> >> > >
> >> > > The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
> >> > >
> >> > > Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+)
> now fail on short
> >> > > dates that fall in a different year from current
> (previous or next).
> >> > >
> >> > > Some of the existing tests assume that dates cannot
> be more than 1
> >> > > hour in the future - IMO this is wrong - so I
> propose to drop these
> >> > > tests.
> >> > >
> >> > > I'm working on a patch which I'll add as a patch to NET-188.
> >> > >
> >> > > On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > >
> >> > >> Sure, you can just add them directly yourself if you like.
> >> > >>
> >> > >> Rory
> >> > >>
> >> > >>
> >> > >> The *nix short date formatting fixes don't
> currently have any tests,
> >> > >> at least when I last checked.
> >> > >>
> >> > >> I think these need to be added first.
> >> > >>
> >> > >> I can add some later today if that's OK with you?
> >> > >> Or do you want them done as patches via Jira?
> >> > >>
> >> > >>
> >> > >> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > >> > Hi James
> >> > >> >
> >> > >> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
> >> > >> >
> >> > >> > Thanks
> >> > >> >
> >> > >> > Rory
> >> > >> >
> >> > >> >
> >>
> >>
> >> <snip/>
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] fixing short date parsing problems (was: [VOTE] Release
Commons Net 1.5)
Posted by Rory Winston <ro...@gmail.com>.
Sebb/Martin
The lenient future dates flag just allows a window of +1 day in the
short timestamp, which if > now(), will not be rolled back by a year.
This is to prevent dates slightly in the future being rolled back
inappropriately. You keep mentioning the +/- 6 month thing - the problem
is that this (like a lot of other FTP stuff) isn't a standard and you
can't depend on it. Still, there are a bunch of other flags in there to
work around other issues, so maybe another flag might be required for
fully comprehensive date handling.
Say if we have a date d ( 1 day < d <= 6 months) in the future, this
flag would control whether d is rolled back (as it would be now) or kept
in the current year (which we would need a flag for).
Is this what is needed to get the remaining tests to pass?
Rory
sebb wrote:
> On 10/03/2008, sebb <se...@gmail.com> wrote:
>
>> On 10/03/2008, Rory Winston <ro...@gmail.com> wrote:
>> > Hi Sebb
>> >
>> > A couple of things:
>> >
>> > 1. Which tests are you referring to in your first point below?
>>
>>
>> testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
>> testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
>>
>> The first one only applies in leap years - it was designed before the
>> addition of the server calendar parameter. It could perhaps be
>> dropped.
>>
>> I've since fixed the following test, and it also fails, but only on 1.4:
>>
>> testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
>>
>>
>> > 2. Does the assumption have anything to do with the lenientFutureDates
>> > flag in FTPTimestampParserImpl?
>> >
>>
>>
>> Yes, the *nix future dates thing is tied in with lenientFutureDates.
>>
>> I suspect there may need to be a new flag which enables *nix style +/-
>> 6 months dates.
>>
>> I don't understand what the lenient flag is about - was it part of an
>> attempt to handle *nix dates (in which case it's wrong, as lenient
>> allows up to 1 year in arrears), or is it for different OSes?
>>
>> The past and future date tests need extending as well; there should be
>> one test where the current date is in the first 6 months of the year,
>> and another where it is in the second 6 months of the year (and
>> perhaps leap/non-leap years too).
>>
>>
>
> The past and future tests have been updated as above.
>
> The future tests fail on both trunk and 2.0.
> However, the cases where they apply are relatively rare, so fixing
> them could be left until a later release.
>
> The Feb 29 failures definitely need to be fixed before trunk is released.
>
> It seems to me that there will probably still be some valid edge cases
> where the date validation fails. AIUI at present this would mean that
> the entire entry is set to null.
>
> Seems to me it would be a lot better if the FTPFile entry was still
> generated, but with a null date.
>
> Not all users need the dates, so this would allow Net to fail more gracefully.
>
>
>> > Rory
>> >
>> >
>> > sebb wrote:
>> > > I've committed updates to the FTPTimestampParserImplTest classes in
>> > > trunk and NET_2_0.
>> > >
>> > > The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
>> > >
>> > > Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) now fail on short
>> > > dates that fall in a different year from current (previous or next).
>> > >
>> > > Some of the existing tests assume that dates cannot be more than 1
>> > > hour in the future - IMO this is wrong - so I propose to drop these
>> > > tests.
>> > >
>> > > I'm working on a patch which I'll add as a patch to NET-188.
>> > >
>> > > On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
>> > >
>> > >> Sure, you can just add them directly yourself if you like.
>> > >>
>> > >> Rory
>> > >>
>> > >>
>> > >> The *nix short date formatting fixes don't currently have any tests,
>> > >> at least when I last checked.
>> > >>
>> > >> I think these need to be added first.
>> > >>
>> > >> I can add some later today if that's OK with you?
>> > >> Or do you want them done as patches via Jira?
>> > >>
>> > >>
>> > >> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
>> > >> > Hi James
>> > >> >
>> > >> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
>> > >> >
>> > >> > Thanks
>> > >> >
>> > >> > Rory
>> > >> >
>> > >> >
>>
>>
>> <snip/>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
> Seems to me it would be a lot better if the FTPFile entry was still
> generated, but with a null date.
I agree.
In the past, commons net ftp has always been using strict parsing,
with the result that some files might have been missed. We have
also seen this on Solaris with certain devices which would have
led to "ls" lines that the regular expressions did not understand.
I think that API-wise in 2.0 there should be special "invalid or
unknown" values for each slot of the FTPFile data, in order to
handle the cases where the parsing fails for any reason.
Setting a "0" date in 1.5 seems to be OK here as well, although
the handling of dates might be sensitive in an environment where
FTP is used as base for virtual file system that performs a "make"
kind of operation (and might thus lead to not re-building parts
of a system).
It's kind of a philosophical choice, but from a user's perspective
I'd prefer seeing a file with a "null" date rather than not seeing
it at all.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Posted by sebb <se...@gmail.com>.
On 10/03/2008, sebb <se...@gmail.com> wrote:
> On 10/03/2008, Rory Winston <ro...@gmail.com> wrote:
> > Hi Sebb
> >
> > A couple of things:
> >
> > 1. Which tests are you referring to in your first point below?
>
>
> testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
> testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
>
> The first one only applies in leap years - it was designed before the
> addition of the server calendar parameter. It could perhaps be
> dropped.
>
> I've since fixed the following test, and it also fails, but only on 1.4:
>
> testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
>
>
> > 2. Does the assumption have anything to do with the lenientFutureDates
> > flag in FTPTimestampParserImpl?
> >
>
>
> Yes, the *nix future dates thing is tied in with lenientFutureDates.
>
> I suspect there may need to be a new flag which enables *nix style +/-
> 6 months dates.
>
> I don't understand what the lenient flag is about - was it part of an
> attempt to handle *nix dates (in which case it's wrong, as lenient
> allows up to 1 year in arrears), or is it for different OSes?
>
> The past and future date tests need extending as well; there should be
> one test where the current date is in the first 6 months of the year,
> and another where it is in the second 6 months of the year (and
> perhaps leap/non-leap years too).
>
The past and future tests have been updated as above.
The future tests fail on both trunk and 2.0.
However, the cases where they apply are relatively rare, so fixing
them could be left until a later release.
The Feb 29 failures definitely need to be fixed before trunk is released.
It seems to me that there will probably still be some valid edge cases
where the date validation fails. AIUI at present this would mean that
the entire entry is set to null.
Seems to me it would be a lot better if the FTPFile entry was still
generated, but with a null date.
Not all users need the dates, so this would allow Net to fail more gracefully.
> > Rory
> >
> >
> > sebb wrote:
> > > I've committed updates to the FTPTimestampParserImplTest classes in
> > > trunk and NET_2_0.
> > >
> > > The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
> > >
> > > Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) now fail on short
> > > dates that fall in a different year from current (previous or next).
> > >
> > > Some of the existing tests assume that dates cannot be more than 1
> > > hour in the future - IMO this is wrong - so I propose to drop these
> > > tests.
> > >
> > > I'm working on a patch which I'll add as a patch to NET-188.
> > >
> > > On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> > >
> > >> Sure, you can just add them directly yourself if you like.
> > >>
> > >> Rory
> > >>
> > >>
> > >> The *nix short date formatting fixes don't currently have any tests,
> > >> at least when I last checked.
> > >>
> > >> I think these need to be added first.
> > >>
> > >> I can add some later today if that's OK with you?
> > >> Or do you want them done as patches via Jira?
> > >>
> > >>
> > >> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> > >> > Hi James
> > >> >
> > >> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
> > >> >
> > >> > Thanks
> > >> >
> > >> > Rory
> > >> >
> > >> >
>
>
> <snip/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Posted by sebb <se...@gmail.com>.
On 10/03/2008, Rory Winston <ro...@gmail.com> wrote:
> Hi Sebb
>
> A couple of things:
>
> 1. Which tests are you referring to in your first point below?
testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
The first one only applies in leap years - it was designed before the
addition of the server calendar parameter. It could perhaps be
dropped.
I've since fixed the following test, and it also fails, but only on 1.4:
testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
> 2. Does the assumption have anything to do with the lenientFutureDates
> flag in FTPTimestampParserImpl?
>
Yes, the *nix future dates thing is tied in with lenientFutureDates.
I suspect there may need to be a new flag which enables *nix style +/-
6 months dates.
I don't understand what the lenient flag is about - was it part of an
attempt to handle *nix dates (in which case it's wrong, as lenient
allows up to 1 year in arrears), or is it for different OSes?
The past and future date tests need extending as well; there should be
one test where the current date is in the first 6 months of the year,
and another where it is in the second 6 months of the year (and
perhaps leap/non-leap years too).
> Rory
>
>
> sebb wrote:
> > I've committed updates to the FTPTimestampParserImplTest classes in
> > trunk and NET_2_0.
> >
> > The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
> >
> > Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) now fail on short
> > dates that fall in a different year from current (previous or next).
> >
> > Some of the existing tests assume that dates cannot be more than 1
> > hour in the future - IMO this is wrong - so I propose to drop these
> > tests.
> >
> > I'm working on a patch which I'll add as a patch to NET-188.
> >
> > On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >
> >> Sure, you can just add them directly yourself if you like.
> >>
> >> Rory
> >>
> >>
> >> The *nix short date formatting fixes don't currently have any tests,
> >> at least when I last checked.
> >>
> >> I think these need to be added first.
> >>
> >> I can add some later today if that's OK with you?
> >> Or do you want them done as patches via Jira?
> >>
> >>
> >> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
> >> > Hi James
> >> >
> >> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
> >> >
> >> > Thanks
> >> >
> >> > Rory
> >> >
> >> >
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] fixing short date parsing problems (was: [VOTE] Release
Commons Net 1.5)
Posted by Rory Winston <ro...@gmail.com>.
Hi Sebb
A couple of things:
1. Which tests are you referring to in your first point below?
2. Does the assumption have anything to do with the lenientFutureDates
flag in FTPTimestampParserImpl?
Rory
sebb wrote:
> I've committed updates to the FTPTimestampParserImplTest classes in
> trunk and NET_2_0.
>
> The 2 additional tests for Feb 29 fail on Java 1.3/1.4.
>
> Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) now fail on short
> dates that fall in a different year from current (previous or next).
>
> Some of the existing tests assume that dates cannot be more than 1
> hour in the future - IMO this is wrong - so I propose to drop these
> tests.
>
> I'm working on a patch which I'll add as a patch to NET-188.
>
> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
>
>> Sure, you can just add them directly yourself if you like.
>>
>> Rory
>>
>>
>> The *nix short date formatting fixes don't currently have any tests,
>> at least when I last checked.
>>
>> I think these need to be added first.
>>
>> I can add some later today if that's OK with you?
>> Or do you want them done as patches via Jira?
>>
>>
>> On 09/03/2008, Rory Winston <ro...@gmail.com> wrote:
>> > Hi James
>> >
>> > Yes, I'm going to cut new RCs for 1.5 and 2.0.
>> >
>> > Thanks
>> >
>> > Rory
>> >
>> >
>> >
>> > James Carman wrote:
>> > > On 3/8/08, Rory Winston <ro...@gmail.com> wrote:
>> > >
>> > >> I've taken into account the suggestions proposed by various people wrt
>> > >> the TFTP server classes and accordingly made some changes. Thanks for
>> > >> the feedback.
>> > >>
>> > >>
>> > >
>> > > So, does that mean you're cutting (or have already done so) a new
>> > > release candidate for us to vote on?
>> > >
>> > >
>> > >> Rory
>> > >>
>> > >>
>> > >> sebb wrote:
>> > >> > On 07/03/2008, Henri Yandell <fl...@gmail.com> wrote:
>> > >> >
>> > >> >> On Fri, Mar 7, 2008 at 8:04 AM, James Carman <ja...@carmanconsulting.com> wrote:
>> > >> >> > On 3/2/08, Rory Winston <ro...@gmail.com> wrote:
>> > >> >> > > Hi
>> > >> >> > >
>> > >> >> > > This is a release vote for Commons Net 1.5. This release fixes a few
>> > >> >> > > issues with TFTP errors, threading hangs, and a leap year date parsing bug.
>> > >> >> > >
>> > >> >> > > The RC deployment is here:
>> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/site/
>> > >> >> > >
>> > >> >> > > Binaries:
>> > >> >> > >
>> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/commons-net-1.5.0-SNAPSHOT-bin.zip
>> > >> >> > >
>> > >> >> > > Source:
>> > >> >> > >
>> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/commons-net-1.5.0-SNAPSHOT-src.tar.gz
>> > >> >> > >
>> > >> >> > > Javadocs:
>> > >> >> > >
>> > >> >> > > http://people.apache.org/~rwinston/commons-net-1.5.0/site/apidocs/index.html
>> > >> >> > >
>> > >> >> > > SVN tag:
>> > >> >> > >
>> > >> >> > > http://svn.apache.org/viewvc/commons/proper/net/tags/NET_1_5_0/
>> > >> >> > >
>> > >> >> > > Here's my +1 in advance.
>> > >> >> > > Cheers
>> > >> >> > > Rory
>> > >> >> > >
>> > >> >> >
>> > >> >> > I just wanted to post my official -1 vote. I feel that the
>> > >> >> > org.apache.commons.net.tftp.TFTPServer class is outside the scope of
>> > >> >> > Commons Net. I have no problem with it being in the test classes, as
>> > >> >> > suggested, though.
>> > >> >>
>> > >> >>
>> > >> >> Not a problem for me. +1 to including the server class.
>> > >> >>
>> > >> >> It's not big codewise, and is not that far from Net's scope or Commons scope.
>> > >> >>
>> > >> >
>> > >> > But it's not in scope (yet?)
>> > >> >
>> > >> >
>> > >> >> Two proviso's:
>> > >> >>
>> > >> >> 1) The main method in TFTPServer should be removed.
>> > >> >>
>> > >> >
>> > >> > +1
>> > >> >
>> > >> >
>> > >> >> 2) If we get lots of embedded server components, then we should
>> > >> >> rethink this, but I can see that the 'simple embedded server space' is
>> > >> >> pretty small. Might want to use a different package to allow it to
>> > >> >> more easily be split out. org.apache.commons.net.server.* or
>> > >> >> something. Then people can send in their dumb EchoServer
>> > >> >> implementations :)
>> > >> >>
>> > >> >
>> > >> > +1 to changing package name.
>> > >> >
>> > >> > I still think it should be in the test tree; AFAICS the purpose of the
>> > >> > code contribution was to enable the TFTP Client to be tested.
>> > >> >
>> > >> > If Commons starts getting other simple server implementations then
>> > >> > these ought to be part of a different project with a scope of
>> > >> > Testing/Mocking or some such. Maybe not even in Commons.
>> > >> >
>> > >> >
>> > >> >> Hen
>> > >> >>
>> > >> >>
>> > >> >> ---------------------------------------------------------------------
>> > >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >> >> For additional commands, e-mail: dev-help@commons.apache.org
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >
>> > >> > ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >> > For additional commands, e-mail: dev-help@commons.apache.org
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >> For additional commands, e-mail: dev-help@commons.apache.org
>> > >>
>> > >>
>> > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org