Hi Daniel You're the second person to raise the issue about swallowing exceptions in less than a week, so maybe there is something that we can look at there. Possibly we could have a configurable "fail-fast" policy for parsing directory entries. On the subject of the OS/400 parser, if there are changes you have made to get this to work, and if you (and/or your employer) are happy to donate them to the project, I would be happy to incorporate them into the existing OS/400 parser implementation in [net], giving you due credit, of course.
Best regards Rory "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org> wrote: > > Hi all, > > I've been using commons-net for FTP for about two years now. It's been > great and we love it (we = the company at which I work). > > But recently our systems have had to interface with an OS/400-based FTP > server. It's been a lot of trouble. > > First, the default date format didn't match what the server was sending > (dd/MM/yy instead of the default yy/MM/dd). Second, the OS/400 parser > only understands the *STMF and *DIR types. But the server I'm working > with has a *FILE type. Additionally, there's a *MEM type too. Which > leads me to the third problem: each file listing seems to be in two > lines. One as *FILE and the other as *MEM. But the *MEM lines don't > include size or timestamp. This results in a null being returned from > parseEntry() (because the REGEX doesn't match). When null is returned, > the parsing is aborted. As a result, I would only ever see the first > file alphabetically in a listFiles() call. > > To solve my problem without hacking/customizing the commons-net 1.4.1 > jar, I subclassed the OS/400 parser to try parsing with two REGEX values. > > Could I suggest changing the core of file entry parsing to not give up > when it gets a null back, but rather to give up when the listing data > stream is done reading? Any null's return by parseEntry() should be > skipped. At the least, an exception should be thrown to indicate > incompatible FTP listing data. > > But, I also discovered that if there's an exception in parsing (null > pointer, runtime, etc), commons-net catches this exception and quietly > returns. IMHO, this should be floated up to the caller to be aware of a > problem in parsing the FTP data. > > Cheers, > Dan > > ======================= > here's some debug I put into commons-net to discover what was being read > from the server. > > > the line read was [CFT 45056 04/12/06 14:19:31 *FILE > AFTFRE1.FILE] > the line read was [CFT *MEM > AFTFRE1.FILE/AFTFRE1.MBR] > the line read was [CFT 36864 28/11/06 15:19:30 *FILE > AFTFRE2.FILE] > the line read was [CFT *MEM > AFTFRE2.FILE/AFTFRE2.MBR] > the line read was [CFT 45056 04/12/06 14:19:37 *FILE > AFTFRE6.FILE] > the line read was [CFT *MEM > AFTFRE6.FILE/AFTFRE6.MBR] > the line read was [QSYSOPR 28672 01/12/06 20:08:04 *FILE > FPKI45POK5.FILE] > the line read was [QSYSOPR *MEM > FPKI45POK5.FILE/FPKI45POK5.MBR] > the line read was [null] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
