commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17224] New: - Method DefaultFTPFileListParser.parseFTPEntry() returns null for an unparsable but non-empty line
Date Wed, 19 Feb 2003 22:41:03 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=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

           Summary: Method DefaultFTPFileListParser.parseFTPEntry() returns
                    null for an unparsable but non-empty line
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Net
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: matthias.glasel@sulzer.de


package: org.apache.commons.net.ftp
class  : DefaultFTPFileListParser
method : parseFTPEntry

The problem occured, when I tried to download the Member-List of an "MVS
Partitioned Dataset". Maybe you're not familiar with that kind of environment.
It can be compared to a directory of a /dos/win/unix/...-filesystem. FTP
produces a listing of "members" (comparable to files in the directory) in the form:

 Name        Size   Created          Changed          ID   
MYPST           9  2003/01/28  2003/01/28 11:10:43  QX05501
OUT             6  1998/10/05  2000/08/10 14:29:20  QX15501
PANELS                                                               
PERFORM       140  1998/02/19  1998/02/23 09:39:04  QX15501

The entry with the name "PANELS" causes the trouble. Although the line isn't
empty, its blank statistics-part makes parseFTPEntry() returning null
(ArrayIndexOutOfBoundsException is being caught).

Sure, DefaultFTPFileListParser is not designed for being able to parse the above
kind of stuff (I have to write a proper subclass for the File-Attributes ...). 

But wouldn't it be better for "Default"-Method, to be more tolerant and return a
FTPFile-Object that at least has the "_rawListing"-Property set?

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message