Closed Bug 144334 (tar.gz) Opened 22 years ago Closed 21 years ago

foo.tar.gz saved as foo.tar.gz.tar

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tom.williams, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 file)

Save As Dialog
98.56 KB, image/png
Details 
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
bug 120327 has been marked verified fixed, and this bug remains. Reopening.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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)
See also bug 141806, foo.tgz saved as foo.tgz.gz.
Depends on: exe-san
Summary: Tar/GZIP files get saved with WRONG file extension → foo.tar.gz saved as foo.tar.gz.tar
*** 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.
Attached image Save As Dialog — 
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.
Alias: tar.gz
Why should Mozilla gunzip a .tar.gz archive in the first place?

We shouldn't.  That's the "various other reasons".
QA Contact: sairuh → petersen
*** Bug 175109 has been marked as a duplicate of this bug. ***
*** Bug 175284 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
*** 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
Keywords: mozilla1.3 → nsbeta1
A simple question : any hope to see this fixed for 1.4a or 1.4b release ? (Sorry
for spamming the bug !)
Keywords: helpwanted
Nav triage team: nsbeta1-
Keywords: nsbeta1 → 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 :)
Assignee: law → file-handling
*** 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?
QA Contact: chrispetersen → ian
> 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.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
>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...
*** 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: