You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2003/02/20 16:05:26 UTC
DO NOT REPLY [Bug 17224] -
Method DefaultFTPFileListParser.parseFTPEntry() returns null for an unparsable but non-empty line
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=17224>.
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=17224
Method DefaultFTPFileListParser.parseFTPEntry() returns null for an unparsable but non-empty line
dfs@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From dfs@apache.org 2003-02-20 15:05 -------
This isn't a bug, although there was a typo in part of the documentation
that I just fixed. parseFTPEntry() either can parse an entry or cannot
parse an entry. If the entry cannot be parsed, the method returns null.
This is by design, not by accident. In your MVS parser, if PANELS by itself
is a valid listing, then you are free not to return null and include an
FTPFile with partial information. However, this is not appropriate for
DefaultFTPFileListParser, which parses Unix style entries.
However, you are encouraged to submit your MVS file listing parser as a
patch that can be included in a future release. The FTP package will likely
be moving to a more easily extended listing parser class structure (see
proposal/ftp2 in the source tree) and we'd like to support as many
listing formats as possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org