Using the CVS source of Mozilla here, freshly compiled with EGCS 1.1.2 on a Red Hat 6.0 i386 system, with glibc 2.1 and GTK+ 1.2.1, (Linux kernel 2.2.7, and on a Pentium 200 MMX with 32 megs of RAM), with a build ID of 1999050422, it seems when I try to do an FTP download from the above URL, 1) The statistics are a bit strange; I notice about 9 or 10 decimal places in the statistics, and sometimes it even goes into scientific notation. 2) When I finally got the file, it was completely corrupted... It did not even begin to resemble what I was expecting, and it was about 5 times larger than what it was supposed to be. VERY odd indeed.

BTW, I still have the corrupted file available, in case it gives you any additional clues. I would attach it here, but Bugzilla doesn't seem to like it. I guess maybe it's too big?

Update: I forgot that Mozilla would automatically un-gzip it. So I tried just un-tarring it, but found that even as a plain tar file, it is corrupted... The tar program returned this error message: tar: Skipping to next file header tar: Only read 7848 bytes from archive flyingwindows-0.2.tar.gz tar: Error is not recoverable: exiting now This is really getting wierder and wierder...

Bill, is FTP download on Linux really this torqued?

I'll have to beg some help from an x-head for this one. Will look at next week.

Move this to M7 ...

paulmac, is this similar to http://bugzilla.mozilla.org/show_bug.cgi?id=5854

no this bug appears to have something to do with the integrity of the file being downloaded, as opposed to a simple crash

All the same, I wonder if this isn't related to bug 5854... In any case, I am willing to wait until Necko lands to look at this further. BTW, Bugzilla will form links automatically if you type "bug ####." Do you suppose you can do this in the future instead of just the bug number alone, so I don't have to open up a new browser window and enter the bug number manually everytime?

Bill, should we move this out a milestone or two until Nekko lands?

Moving this to M9 until after Nekko lands.

*** Bug 8897 has been marked as a duplicate of this bug. ***

Okay, now that Necko has landed, I thought I'd give a further update: When I visit the given URL again, I now get a popup "Unknown File Type" box. This shouldn't be, since the URL is for an FTP directory, not a file.

ftp doesn't seem to be working at all so I can't do anything with this one. Will try again when ftp comes back online (see bug #12834).

There must be something funky about that particular ftp server. I can successfully browser other ftp: directories (e.g., ftp://hobbes.nmsu.edu/). I'm reassigning this to valeski who hacks the ftp protocol handler. If he determines that the protocol handler is doing the right thing, then I'll look at it again from my end.

I can access the site just fine (a little slow though)

Hot damn, it works for me, too (at least today). I'll hurry up and marke it resolved.

I'm using Build ID 1999112108 on Linux, and I'm experiencing more FTP problems. The test link shown above (ftp://hobbes.nmsu.edu/) opens up an "Unknown File Type" box. Also, when trying to download the latest nightly build for Mozilla (ftp://www.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.gz in my case), it goes to the download window, waits a few seconds, and then pops open a box that says "Unknown topic: component://netscape/appshell/component/xfer;onError Data: 2 8052E891". After closing the box, a new one appears, and I am eventually forced to kill the download and Mozilla with it.

Should we re-open this bug then?

Sigh. ftp://ftp.sonic.net/pub/users/nbs/unix/x/flyingwindows/ produces a ftp directory listing. Clicking on the tar.gz file in that directory produces a crash in nspr event queue code. At least that's what it does on WinNT. My Linux build downloads it fine. That's bug #1. ftp://hobbes.nmsu.edu/ produces a ftp directory listing. I can't descend any subfolders. though. I can add the subdirectory name to the URL in the urlbar, though. That's bug #2. ftp://www.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.g z generates an error because that file doesn't exist at the server. This error isn't handled by Mozilla, however. It generates an unknown-content dialog. If you choose "Save file..." it "successfully" downloads 0 bytes (ignoring the fact that there is no file at that URL). That's bug #3. I'd like to use this bug report to track bug #1 (since current behavior resembles the original bug report). The other two bugs are either covered by other bugs or I will open some. I'll dig deeper into why it's failing to download files from that one location in today's Windows build.

Clearing WorkForMe and reopening.

Setting to M12, since M11 is outta here!

Jeez, let's move this to M14 if warren is gonna fix bug #12834 until then.

Worry about this later ...

Going to <URL:ftp://ftp.sonic.net/pub/users/nbs/unix/x/flyingwindows/> and clicking on "flyingwindows-0.2.tar.gz" works just fine for me as well under Linux, using build 2000030316. I'm changing OS to Windows NT per law's comments, and changing the summary to be a little more descriptive.

Bill, is this still a bug? If not, close it ASAP, please.

This is working (for the moment). If download breaks again, do we really have to go and re-open every single "download didn't work" but that was ever written? Please, let's not.

sorry fot the spam, changing QA contact.

verif.