Mozilla M17 BuildID: 2000080712 The output of that FTP server's LIST command is not shown correctly, Mozilla fails to show file names. No download possible (with lftp, it is possible). Note that the RFC 959 LIST output is not meant to be parseable :-/ Reproducible: Always Steps to Reproduce: Switch off Proxies for FTP, go that site. Actual Results: Some information on the files has been shown, but not the filenames themselves. Expected Results: It should have properly listed the files. The format that that server uses is shown at: http://cr.yp.to/ftp/list/eplf.html

->rjc

confirming, linux CVS from this morning

Note: 4.x doesn't support this server's FTP output either.

Actually, Frederick Roeber added EPLF support to Netscape in 1997. ``Any future browser release from us should support it,'' he said. Unfortunately, the EPLF support was lost when the old FTP-parsing code was replaced with nsFTPDirListingConv. Fixing this should take about five minutes; EPLF is, by design, extremely easy to parse. The goal of EPLF is to clean up the FTP LIST-parsing mess. The idea is for every FTP client to learn how to parse EPLF; then servers can switch to EPLF; then clients won't have to bother parsing other formats. EPLF support is already in Voyager 3, Lynx 2.6, Mirror 2.9, EMirror 2.1, Fetch 3.5, gFTP 2.0.0, lftp 2.2.0, ftpcopy, and Squid 2.3.

Hi dougt, welcome to necko :)

Adjusting summary.

Need to testing this on windows. Also need to especially test on the mac because of the 64 bit math. D. J. Bernstein, it didn't take 5 minutes as you asserted, but it didn't take 5 hours either. :-) One question for you, the way that I test for EPLF format is that the LIST response's first char is a plus ('+'). Is this a correct premise or is there a better way to detect EPLF? Jud, could you code review the patch attached as it stands? If Dan agrees that the way I am detecting EPLF is correct, I would like to see about checking this in.

Yes, simply test for +. The + was designed to distinguish EPLF from all other existing formats. By the way, you shouldn't use size unless flagsize is set.

gagan, jud, can I get a r= on this?

r=valeski

chris, can I get a sr=?

- Please outdent "case 's'" through "default" to line up with "cast '\t'". - I'm worried about someone creating a buffer-overrun situation with your unchecked ASCII-to-decimal conversion. This is a common way to exploit a security hole, and although I can't prove you've created a hole here, you might as well check `*line' to make sure it's between '0' and '9'. Do those things, and sr=waterson.

Nit-picking to uphold Roman and Mozilla common law: + // Mutiply what the last modification date to get usecs. Typo, also trailing whitespace on this line and others. + PR_ExplodeTime(usecs, PR_LocalTimeParameters, &thisEntry->mMDTM); + } else { + thisEntry->mSupressSize = PR_TRUE; What's the indentation unit, two spaces or four? The sacred Emacs modeline comment says 4 (with a nonsensical tab-width of 2, but the indent-tabs-mode: nil makes that moot). Please use four-space indentation. All other switches in this file exdent their case and default labels to the same column as the switch keyword. So should this one, and its case statements then won't be in a half-world of two-vs-four-space indentation. /be

mass move, v2. qa to me.

This has been fixed for a while.

-> ftp

VERIFIED: Mozilla 1.0 RC1, allplats. +testcase This has been a testcase for a while...