From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 2002051006 When I try to download the apache_1.3.24.tar.gz file, the file was saved as apache_1.3.24.tar.gz.tar. "*.tar" was the default file type in the Save As dialog. Reproducible: Always Steps to Reproduce: 1.Go to http://www.apache.org/dist/httpd/ 2.Try to download the apache_1.3.24.tar.gz file 3.File Save As dialog will have "*.tar" as the default file type and file will be saved as apaceh_1.3.24.tar.gz.tar Actual Results: TAR/GZIP file saved with .tar file extension AFTER the .gz extention. Expected Results: The .tar extention should NOT be appended to the end of a .tar.gz file.

sounds like a special case (or dupe?) of Bug 120327.

That's where it'll be fixed.. *** This bug has been marked as a duplicate of 120327 ***

v

bug 120327 has been marked verified fixed, and this bug remains. Reopening.

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

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

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

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

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

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

WFM (2002082104, WinNT)

Not WFM 2002082209 trunk on WinXP http://www.apache.org/dist/httpd/httpd-2.0.40.tar.gz http://www.apache.org/dist/httpd/apache_1.3.26.tar.gz

See also bug 141806, foo.tgz saved as foo.tgz.gz.

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

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

This is really annoying since it changes the filetype so helper apps are confused. For exemple, on the given apache files, moz offers to open winzip. If one tries that, winzip will choke on the (wrongly named) file since it thinks it is a TAR file. The user gets : "Error reading header after processing zero entries" So downloading a tar.gz on windows become : 1-download & save. 2-rename file to remove the extra ".tar" 3-open file with app Instead of: 1-download and open with helper app. Mozilla 1.2alpha, Windows2000

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910 NOT FIXED in this build! Test: attempting to download newer Mozilla 1.2a for linux, go to http://www.mozilla.org/releases/ in the Mozilla 1.2a section, go to Linux section (not the try these section) and click on the link "x86 Talkback enabled Full Installer" that points to http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2a/mozilla-i686-pc-linux-gn u-1.2a-sea.tar.gz Mozilla will ask to save a file named mozilla-i686-pc-linux-gnu-1.2a-sea.tar.gz.tar

Replying to Comment #17: WFM with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2a) Gecko/20020910 Mozilla 1.2a on Windows NT BTW: If you're running Windows 2000, why does your User Agent string say "Win95"?

The poster of comment #17 doesn't say that they are using Windows 2000. That is comment #16. And, unless Mozilla has some sort of fork in the code for Windows NT, this does not work. Click on any link provided in this bug to download foo.tar.gz and choose to save it and you will see it is named foo.tar.gz.tar.

On this screenshot, I downloaded and saved http://www.apache.org/dist/httpd/httpd-2.0.40.tar.gz from comment #12. Mozilla suggested to save the file as httpd-2.0.40.tar.gz and that's also what ended up being on my harddrive.

Your screenshot shows the correct file name, and interestingly, the correct file type (*.gz). There must be something about either the German localizations, or Windows NT that is making Mozilla behave properly on your system. Mozilla misbehaves on WinXP, Win98, WinME, and Win2k here.

One more data point. I'm currently using 1.2a on windows2000 SP3. if file link by clicking i.e. mozilla asks do I want open it by application or save it I get this tar.gz.tar file. If right click the menu and select save as I get the correct file name (tar.gz)

That's it. Sure enough. Same behavior on WinXP.

Re Comment #21: I'm not using a German localized version of Mozilla at work on Windows NT. I'm using the plain, old "original" English version and I also don't have a German language pack installed. On my system, I always get the correct file name. Ie. it doesn't depend on whether I left click->save the file or if I do right click->Save Link Target As... Don't know if this might be important or not, but I'm using the Orbit 3+1 1.0 0.0.5 theme from Chris Neale (morbit@cdn.gs). I've now tested it on my German Windows XP system at home, and when I click on http://www.apache.org/dist/httpd/httpd-2.0.40.tar.gz, Mozilla suggests to save the file as httpd-2.0.40.tar.gz. Also on my home system, I always get the correct file name (ie. on both left and right->Save Link Target As... clicks). The only thing that my work NT system and my home XP system have in common, is that both times I'm using a German Windows version. At work, .tar.gz files are associated with WinRAR; at home it's PowerArchiver (if that matters). User-Agent at home: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910

This bug is also showing up on .MPG files and .WAV files...

In an attempt to stem the flood of "me-too" and "I wonder why" comments, the deal here is: 1) The url must be being served as "Content-type: application/x-tar; Content-encoding: gzip" 2) We decide "oh, it's of type 'tar'; it should have extension 'tar'". 3) We're not very good at removing extensions, so we just append "tar" 4) [The worst part.] We actually _do_not_ gunzip as we save (for various other reasons). So the extension ends up in fact not matching the data type. The correct fixes for this would be: A) Fixing step 2 to consider the encoding if we're not planning to decode or B) Not doing extension-fixup at all in this case B is arguably more correct but much more tricky. A should be somewhat straightforward; all the parts are already in nsExternalHelperAppService; they just need to be put together.

Why should Mozilla gunzip a .tar.gz archive in the first place?

We shouldn't. That's the "various other reasons".

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

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

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

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

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

If the file is send via script mozilla takes the extension of the script and adds it to the file name. Example: many of the files on www.cracks.am (http://www.cracks.am/d.x?24582 for instance) If the mime type is specified mozilla adds the extension of the mime type to the filename (i.e. if you download a file a.tar.gz with mime type application/x-tar it becomes a.tar.gz.tar). Mozilla also does not look for the file extension but only at the extension of mime type. This is wrong. example: http://www.python.org/doc/current/download.html (html downloads (zip, gzip, bz2)) I have winzip assosiated with .zip and .gz files, but powerarchiver with .bz2 files. But mozilla simply takes the extension of the mime type (application/x-tar), which is .tar and want to open all files with winzip(assosiated with .tar) instead of using correct application for .bz2 files.

Which has NOTHING to do with this bug. This bug is about saving. There is a TOTALLY separate bug on the helper issue you describe and that issue is a very different kettle of fish altogether. Please don't spam this bug with irrelevant comments.

I couldn't find the bug you mention, so i reported it as Bug 180179, but it has been marked as duplicate of this bug

> bug 132702 "Mozilla doesn't display image in helper app" ? No wonder folks are filing duplicates...

Feel free to suggest a better summary in that bug. I failed to think of one under 100 chars...

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

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

Most of the comments to this bug refer to addition of ".tar". The problem also occurs with other extensions and appears to lie in the functioning of Down Load manager. When operating under Windows 2000 with Mozilla versions 1.0 through 1.2.1, download manager appends a ".bin" to the names of files being downloaded. Thus "mozilla-win32-1.2.1-installer.exe" becomes "mozilla-win32-1.2.1-installer.exe.bin". The problem only occurs when the file is downloaded from "http://ftp.mozilla.org/..." which is the path from the Mozilla home page. Download manager states that "you have elected to download a file type: "binary executable" [application/octet-stream} from http://ftp.mozilla.org/pub/mozilla/releases/..." The header of this window reads : "downloading Mozilla-win32-1.2.1-installer.exe.bin" and that's exactly what it does! If one goes directly to the ftp location "ftp://ftp.mozilla.org/..." then the downloaded file is correctly named and saved. Reproducibility: every time will all releases including the Netscape 7.0 step-child. Also happens with other web sites. What should the result be : No change in the file name Suggestion: Since many people use Mozilla to down load files should this bug and the work around (save to disk and rename the file" be listed in the release notes?

When trying to reproduce the problem with other than .tar files, as mentioned in comment #42 by Matt Krause, when I attempted to download: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2.1/mozilla-win32-1.2.1-installer.exe by clicking on it, Mozilla 1.2.1 hangs. It does this consistently. This sounds like a slightly different (although possibly related) problem. I'm using Win XP Pro (SP1). The original bug occurs at other web sites -- see bug #183996 which was marked as a duplicate of this one. In that bug the file name was changed from ".tgz" to ".tgz.tar".

There's a reason this is filed as a separate bug from the other extension-munging bugs. It's because it's a different problem. The issue here is that there's a content-disposition involved, unlike most cases. It's perfectly feasible (and likely to happen) to fix the other extension-munging issues without fixing this one. Which is why it's being kept separate.

Since I wrote comment #42 I have resolved my problem (Addition of ".BIN" to the file name) . I had tried clean installs of Mozill after totally deleting all folders. this was unsuccessfull. My "renaming" problem was finally curred by creating a new profile from scratch. Now both Netscape and Mozilla have their own profiles and everything seems fine.

file.mp3 saved as file.mp3.mpeg Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210 (remove it if it disturbs! I'm bugzilla beginner!)

i'm seeing this with other file types as well (.wma and .mp3 off the top of my head) ... win2k 2003021008

A simple question : any hope to see this fixed for 1.4a or 1.4b release ? (Sorry for spamming the bug !)

Nav triage team: nsbeta1-

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

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030326 Also, a ".zip" extension added when saving a ".gz" file such as: ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-sparc-sun-solaris2.7.tar.gz Instead of the file saving as mozilla-sparc-sun-solaris2.7.tar.gz it saves it as mozilla-sparc-sun-solaris2.7.tar.gz.zip

Ive just found as of mozilla 1.4b and firebird 22ns may build that its adding ".x" to any zip file i download. I just reinstalled windows XP pro and copied over my old firebird folder, bookmarks and prefs.js files to the new profile folder. It WASNT doing this with zip files before i reinstalled XP even though its exactly the same physical install of firebird.

That's bug 188058, and any help tracking it down would be appreciated.

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

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

True story. Independent of website.

See the more general bug 163254.

bug 163254 is not more general, it is about a different issue.

Actually, ostgote@gmx.net is right. Both this and bug 213516 are duplicates of bug 163254. 213516 has already been marked duplicate, can someone please dupe this one?

can you just trust me that these two bugs are about different issues? This one is that for application/x-tar files, the .tar extension gets appended; that one is that the primary extension of a mimeinfo gets appended even though it may be wrong. also see comment 26 where bz explains this issue perfectly. comment 44 contradicts that but seems wrong :)

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

interesting... this is almost fixed. bug 128199 (fixed in march 2002) corrected the "save link target as" part the helper app dialog should be fixed because we no longer do extension fixup for it (when using "save as"). (bug 164816, fixed in october 2003 for 1.6alpha and later). The only question that's left is whether externalhelperappservice (responsible for the helper app dialog) should do what the "save link target as" codepath does and use the content encoding's mime type for mime info lookup (if content decoding is not done). The problem with doing that: The server sent application/x-tar, but we won't use tar's helper app; that may confuse users. if we aren't careful, we'd also display the wrong mime type. What doing that would gain us: Helper apps that support application/x-tar (as an example) files don't necessarily support application/x-gzip files. bz, any opinion?

> and use the content encoding's mime type for mime info lookup (if content > decoding is not done). Actually, the problem is that this stuff is all ass-backwards. What we _should_ do is: 1) Do MIME info lookup on the server provided type 2) Suspend the channel while the user decides what to do 3a) If the user chose a helper app, always decode 3b) If the user chose to save, use the current logic to decide whether to decode. The problem of passing compressed data to apps that may not expect it in the current arch is covered by an existing bug (I thought it was assigned to me, but I can't find it -- darin was cced and the bug talked about .doc.gz files being sent as application/msword with gzip encoding, iirc).

>2) Suspend the channel while the user decides what to do right... once we fix streamlisteners... >3a) If the user chose a helper app, always decode that's a good point, hence marking this FIXED per comment 62.

>darin was cced and the bug talked about .doc.gz files being >sent as application/msword with gzip encoding, iirc). that seems to be bug 128199 comment 6

Ah, yes. That was it. I don't know how you find these... ;) In that case, we may want to file a separate but to track that issue...

filed bug 229870

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

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

This bug is definitely not fixed. This still happens for me with versions 2.0.0.1 and 3.0a2pre (build Jan 25), but only when saving to a FAT32 file system. Saving to my /home, which is XFS, works without problem. File names are changed as follows: foo.tar.gz becomes foo.tar.gz.tar foo.exe becomes foo.exe.bin or foo.exe.exe foo.zip becomes foo.zip.zip

Please file a new bug for that with complete steps to reproduce.