ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14333] - FTP depends/newer option does not work
Date Mon, 10 Mar 2003 02:32:40 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14333>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14333

FTP depends/newer option does not work





------- Additional Comments From scohen@apache.org  2003-03-10 02:32 -------
I have been talking about this on the commons-dev mailing list as it pertains to commons-net
(formerly NetComponents).  Fixing it there will be a prerequisite of fixing it here.  First
off, I am talking only about date parsing and the depends/newer option.  The other problem
identified by Scott Bellamy and David Ishee seems like a totally different problem which should
be addressed in a separate bug report rather than tacked on to this one as its solution will
be completely different.  You should know that there are new parsing options in commons-net
that can and should be supported in the <ftp> task.  FTP parsers for NT, OS2, and VMS
FTP servers have been created in addition to unix and support for these could now be added
to ant.  However these only take us part of the way toward solving this bug and implementation
of the ant-side fix may want to wait until the net-components piece is fixed.  Here is what
I wrote on the commons-dev mailing list:  ---------------------------------------------------------------
 I have been thinking about the issue, though, in particular where commons-net.ftp might have
to go in order to really implement the ambitious spec laid out for it by clients such as ant,
which have chosen to use it.   Of particular note here is the "depends" (or synonym "newer")
attribute of the ant <ftp> task.  This runs aground on the issue of parsing the date.
 In the first place, there are the issues of general listing format (unix, NT, VMS, etc.).
 In the second place, though, within these categories are issues of date format.  This devolves
into a thicket of locale-type issues:   Does month come before date?  In which language are
the names of the months coded?   To solve this, the scope of parser definition needs to be
significantly expanded.   Things might be better if there was any mechanism within the FTP
specification for the server to expose its format to a client.  No such mechanism exists,
however.  In fact RFC959, the FTP spec is intentionally vague on this point:   "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."   http://www.ietf.org/rfc/rfc959.txt
  In other words, FTP was never meant to be used in such an automated fashion.   Nonetheless,
with the specification of parameters easily passed in by something like an ant task, it might
be possible to define a parser sufficiently to perform this task.  These parameters include:
  1) os type of FTP server(unix, NT, OS2, VMS, etc.) 2) date format - to define ordering of
date components -  "MMM dd" or "dd MMM", etc. as in simple date format 3) locale - to define
actual abbreviations of the months.    From 2 and 3 it is possible to build a Locale-specific
SimpleDateFormat  capable of parsing dates on a particular system.  This object contains the
    names and abbreviations of the month.   This immediately raises the question of how to
divvy up the parsing duties between the regular expression and the SimpleDateFormat.   It
seems as if the format string must be used to construct the part of the regex in the correct
order.  Then the SimpleDateFormat would be used to actually parse the date.  All "optimizations"
such as assuming a constant character width of 3 for month abbreviations are out the window
here - they work for many languages, but not for all.  French, for example, uses periods and
varying lengths.   A cautionary note: one would have to inspect actual ftp sites to determine
whether they actually the abbreviations specified in java Locales.   ----------------------------------------------
 What I would like, especially from those who submitted and added to this bug, are the addresses
of particular ftp non-English ftp servers that I could log into for the purposes of "getting
the lay of the land" before I begin coding a solution

Mime
View raw message