commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oberhuber, Martin" <Martin.Oberhu...@windriver.com>
Subject RE: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Date Wed, 12 Mar 2008 09:54:05 GMT
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 <sebbaz@gmail.com> wrote:
> >   
> >> On 10/03/2008, Rory Winston <rory.winston@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 <rory.winston@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 <rory.winston@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


Mime
View raw message