Closed Bug 6141 Opened 25 years ago Closed 24 years ago

FTP download crashes

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: zuperdee, Assigned: law)

References

(
URL
)

Details

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...
Assignee: don → law
Priority: P3 → P1
Target Milestone: M6
Bill, is FTP download on Linux really this torqued?
Status: NEW → ASSIGNED
I'll have to beg some help from an x-head for this one.  Will look at next week.
Target Milestone: M6 → M7
Move this to M7 ...
QA Contact: leger → paulmac
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?
Component: Apprunner → XPApps
Target Milestone: M7 → M9
Moving this to M9 until after Nekko lands.
*** Bug 8897 has been marked as a duplicate of this bug. ***
Target Milestone: M9 → M10
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.
Depends on: 12834
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).
Assignee: law → valeski
Status: ASSIGNED → NEW
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)
Assignee: valeski → law
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Clearing WorkForMe and reopening.
Target Milestone: M11 → M12
Setting to M12, since M11 is outta here!
Target Milestone: M12 → M14
Jeez, let's move this to M14 if warren is gonna fix bug #12834 until then.
Blocks: 20870
Target Milestone: M14 → M15
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.
OS: Linux → Windows NT
Summary: FTP download is wierd... → FTP download crashes
Bill, is this still a bug?  If not, close it ASAP, please.
Target Milestone: M15 → M16
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
sorry fot the spam, changing QA contact.
QA Contact: paulmac → sairuh
verif.
Status: RESOLVED → VERIFIED
No longer blocks: 20870
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.