From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011121 BuildID: 2001112108 In FTP, clicking on a tar.gz file causes it to immediately begin downloading to a local file, but the name of the local file is gibberish, not the base name of the file on the ftp server. This problem occurs only when clicking on the ftp dir entry link. If you use (right click)->Save Link As... then the destination file name is defaulted correctly. Reproducible: Always Steps to Reproduce: 1.open ftp://gatekeeper.dec.com/pub/GNU/gdb 2.click on gdb-5.0.tar.gz Actual Results: A "Saving File" dialog pops up with "To: /tmp/b68npmyi.gz" and mozilla immediately begins writing that garbage file name. Expected Results: The To: file name should be gdb-5.0.tar.gz, not b68npmyi.gz

Does the file get renamed to the correct name once the download is done?

wfm using build 2001112111 on Linux. I don't see any garbage.

When I do this, the file is not renamed. After the download finishes, /tmp/b68npmyi.gz is left intact.

-> file handling, and I think this is a dupe

Any new ideas where this bug is coming from? I still see it half the time using the lastest nightly. With Linux 2001121308, if I start mozilla with the command mozilla ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-12-13-09-trunk/mozilla-gcc30-i686-pc-linux-gnu.tar.gz then it immediately starts downloading to a random file name such as /tmp/u1u8f3yn This also happens sometimes when clicking on links, but not always. Could my .mime-types file affect this? Any other sugestions for isolating the cause? I think this must be fixed for 1.0

Your mailcap file could well be affecting this. Does ~/.mailcap or /etc/mailcap contain anything to do with "zip", "tar", or "gz"? Furthermore, what is the effect of going to Edit > Preferences > Navigator > Helper Applications and clicking the "Reset" button near the bottom of the panel?

Aha! Clicking "Reset" of file open preferences made the symptom go away. Now starting "mozilla ftp://blah/blah.gz" brings up a dialog with "Open using gunzip" pre-selected. If I click "Save to disk" then the next dialog has the correct file name. But I didn't think to copy my .mozilla dir first, so the data which caused this buggy behavior is, I fear, lost. Something caused my settings to be put in a state which caused this aberrant behavior (presumably a bug which still exists, but that is not certain). P.S. egrep 'zip|tar|gz' $HOME/.mailcap /etc/mailcap yielded: /etc/mailcap:application/x-gunzip; gunzip -c %s; copiousoutput /etc/mailcap:application/x-gzip; gunzip -c %s; copiousoutput /etc/mailcap:application/x-bunzip2; bunzip2 -c %s; copiousoutput /etc/mailcap:application/x-tar-gz; gunzip -c %s | tar -tf -; copiousoutput

Aha. Thought so. Here's the deal. :) The original version of the mailcap code that I checked in would disable the "what to do" prompt if it found a helper app that matched the type (as I have since discovered this is a bad idea because RedHat sets up incredibly crappy default helpers). In your case it found such an app for application/x-gzip and so would just use the helper to open the file. Now the helper app is a pretty stupid one, so it just unzipped the file (which we name with a random name for security reasons). So you saw what you saw -- the file got downloaded and saved with a random name (then uncompressed, but that's not easy to tell unless you run 'file' on it). At some point Bill fixed helper app stuff so that the "don't ask" thing actually got persisted in prefs correctly. So you had a preference that basically said "never prompt before opening application/x-gzip files, just open them". The "Reset" button in mailnews reset that pref, so you got the prompt. Now the good news is that the underlying bug is fixed as of a few days ago. Going to mark a duplicate of that... if you think that there's something else that should really be done here, feel free to reopen. If you ever see this again, thwack me and then reopen. :) *** This bug has been marked as a duplicate of 113908 ***

v