Closed Bug 50420 Opened 24 years ago Closed 24 years ago

File downloaded as aim-1.1.41-1.i386.exe rather than aim-1.1.41-1.i386.rpm

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: wd, Assigned: mscott)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [se-radar][nsbeta3-] relnote-user) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20000825
BuildID:    2000082508

When I went to download a file from the above URL, I noticed that the file
downloaded is test.exe , rather than the expected file.  It's not just a naming
problem, either...   test.exe is not the file with just a different filename.


Reproducible: Always
Steps to Reproduce:
1.  Go to:  http://www.freeveracity.org/download.shtml
2.  Click on one of the links to download
3.  Save onto your computer

Actual Results:  The file saved is some unknown test.exe

Expected Results:  The correct file is downloaded

This has happened to me on another site, too, but I forget which one.   If you
click on the link a second time, the correct file will download.
this is a dup of law's bugs.
Assignee: gagan → law
I can dup this problem by trying to download the file from this page:

http://rpmfind.net/linux/RPM/contrib/libc6/i386/xanim-28010-3.i386.html
*** Bug 51011 has been marked as a duplicate of this bug. ***
would this perchance be related to the problems seen in bug 48889?
Keywords: correctness, nsbeta3
OK, my original bug description was wrong.   It *is* just a naming problem.   If 
I take the downloaded file and put a .tgz extension on it, it opens in Winzip 
just fine.
Reporting comments form dupe bug 51011:

URL: http://www.mozillazine.org/
to repro:

1. go to the above URL, click on the link for the Windows build (which is a zip 
file, called mozilla-win32.zip).

2. the Downloading dialog appears (also, background downloading occurs, as seen 
in the progress meter in the statusbar, as expected). click the Save on Disk 
radiobutton (note, i did this while background downloading is occurring).

3. the native Save File dialog appears.

result: the default name in the filename field is "test.exe"

expected: the default name should be mozilla-win32.zip.
Blocks: 50326
nav triage team:
3+, P1
Priority: P3 → P1
Whiteboard: [nsbeta3+]
i was trying to download an .rpm file, and the extension was changed (but not
the filename) from rpm to exe --is this the same bug? if not, do let me know and
i'll open another bug.

steps (i'm using 2000.09.05.04 opt comm bits on linux, rh6.2):

1. go to http://www.aol.com/aim/Linuxbeta.html, and scroll down to the Download
and Install section.
2. click the "rpm" link (which points to
ftp://ftp.newaol.com/aimgen/73010/aim-1.1.41-1.i386.rpm).
3. the Downloading dialog appears, click the Save to Disk radio button then the
OK button.

result: the file picker appears with aim-1.1.41-1.i386.exe as the filename; in
the "files of type" droplist, ".exe" is selected.

I've figured out what's going on, at least to a certain level (beyond which I 
don't care to venture at this point).

There is no funky auto-encoding going on here (it's an ftp url so that wouldn't 
be applicable anyway?).

The problem is that the url is somehow acquiring a trailing '/'.  We get the 
"suggested" save-as name by calling GetFileName on the url.  Because of the 
trailing '/', the file name is empty.

It is not clear where the trailing slash comes from.  We call GetURI on the open 
(ftp) channel, then GetSpec on that URI (after QI'ing to nsIURL, I believe).  My 
theory is that the ftp protocol handler is getting confused, perhaps due to 
something quirky this particular ftp server is doing.

Anyway, the solution is to properly preserve the URL so that our extraction of 
the suggested save-as name works as intended.

I'm reassigning this (back) to Networking; removing [nsbeta3+].

P.S. Gordon has a bug with a similar symptom (a ftp url acquiring a trailing 
'/').
Assignee: law → gagan
Whiteboard: [nsbeta3+]
Sarah, that seems to be another instance of the same problem.  I noted (with my
debug code) that this url is acquiring a trailing '/' also.  I'm not sure
why/how it is still remembering the file name, though.
I noticed that this seems like maybe it is fixed in yesterday's (2000090508)
build.  I will refresh my debug build and see what's going on.
Yep.   With 2000090608, I am not seeing the behavior I originally reported here. 
  This should probably be marked as FIXED or WORKSFORME
(I'm not sure which one to use when something starts working?)
I still get this bug with 2000090708 (the latest build) under Linux. So, please
don't mark as "works" yet. I first noticed it on ibm.com, but can duplicate it
exactly as described by Liberman below.
hmm.. maybe related to rjc's recent fix for trailing slashes in FTP.
Assignee: gagan → rjc
This seems only to happen when clicking on an link that points to the file
through ftp, when the exact same ftp url is given in the urlbar the name of the
file is correct.
Using sairuh's test with getting AIM for Linux, I still see this with a build 
from the tip.  Its not an FTP problem, I suspect its a problem with the file 
save dialog. Over to bryner as he's been working on it lately.

Brian, you can use sairuh's steps to reproduce this.
Assignee: rjc → bryner
Let's not morph bugs. If the original steps don't reproduce the defect you're
seeing, please open a fresh new bug report.  As written, this is WFM, though I
can't get to the original link.
Peter, I don't believe this bug has morphed. I couldn't get to the first link
either, so I tried sairuh's test case and COULD reproduce the problem.
Okay, I can get a '.exe' extension in the save dialog following Sairuh's steps
on Win98 and Linux (OS->ALL). That is still a far cry from 'Test.exe', but
whatever. However, as Andreas points out, this works fine when you enter the
same URL in the location bar, so I don't see how the filepicker code could be at
fault.  What code could be modifying the URL after the click, but not after the
Enter?
OS: Windows 98 → All
Priority: P1 → P3
Same results on Mac, Platform->All.  Since Mac doesn't use the same filepicker,
I'm pretty sure this is someone trying to munge the extension into something
known.  Munging the extension, especially to .exe, is particularly useless on Mac...
Hardware: PC → All
adding se-radar to status so that i can find this bug more easily. pls don't
remove it [yet], thx.
Summary: File downloaded as test.exe , rather than filename.tar.gz → File downloaded as test.exe, rather than filename.tar.gz
Whiteboard: se-radar
so if this isn't a filepicker bug, why is it assigned to me?  who should get it?

I don't know, a caller, some glue code,...?  Could you check it out?
This is *not* (I repeat) a problem with the file picker or the "save dialog" or 
anything else like that; please see my previous (detailed!) explanation.  The 
problem is inherent in the ftp channel and uri/url.

The front-end code could maybe *fix* the problem symptom, but it is not the 
cause.

BTW, the reason you don't see the problem when you type in the url is because in 
that case we extract the file name from the typed-in URL.  When you click on the 
link, we get the file name from the open ftp channel (which behaves as I 
described previously).
cc law.  Bill, perhaps you could chat with RJC about where the problem lies?
(To semi-quote law)  This is *not* (I repeat) a problem with FTP.

A few minutes of stack crawling reveals that this is a problem with the 
uriLoader, specifically in nsExternalHelperAppService.cpp where it is creating a 
temp file to download the remote FTP file contents into... it just gives the 
temp file a name where it strips off the real extension and then adds on a 
computed one (reference:  line #486 of nsExternalHelperAppService.cpp)

mscott's fingerprints are all over this file... so moving this bug over to him.
Assignee: bryner → mscott
I should probably just be glad that this isn't my bug any more...but I feel 
obliged to try to work towards the real solution.

There *is* a "problem" with FTP.  The URL in question magically acquires a 
trailing '/' which then causes all hell to break loose.  Despite additional bugs 
that might be perceived to lie elsewhere (e.g., in nsExternalHelperAppService), 
the fact that the url morphs is at the root of the symptom reported here.

If, by chance, FTP didn't screw up the URL, then all would be well.  The 
uriloader code would determine the proper extension (.gz).  It would also get 
the proper file "name" (filename.tar).  It would then properly attach the proper 
extension to the proper file name (yes, at about line 486 in 
nsExternalHelperAppService.cpp) and suggest the proper save-to file name 
(filename.tar.gz).

But no.  Instead, the FTP channel gives us a URL that is wrong: it has no "file 
name".  One consequence  is that we are forced to guess as to the extension.  
Our guess, haphazard as it might be, is ".exe".

I tried to say this before:

>The problem is that the url is somehow acquiring a trailing '/'.  We get the 
>"suggested" save-as name by calling GetFileName on the url.  Because of the 
>trailing '/', the file name is empty.

>It is not clear where the trailing slash comes from.  We call GetURI on the 
>open 
>(ftp) channel, then GetSpec on that URI (after QI'ing to nsIURL, I believe).  
>My 
>theory is that the ftp protocol handler is getting confused, perhaps due to 
>something quirky this particular ftp server is doing.

>Anyway, the solution is to properly preserve the URL so that our extraction of 
>the suggested save-as name works as intended.

I'm sorry if I failed to adequately communicate what was happening.  There is 
little question as to what code is producing "test.exe".  It ain't the FTP 
channel.  But the problem isn't that "test.exe" is being generated.  The problem 
is that "filename.tar.gz" is *not* being generated.  And *that* is the direct 
result of the attachment of the trailing '/' to the ftp channel uri/url.

Reassigning back to rjc.
Assignee: mscott → rjc
Oops.  I erred.  That should be GetFileName in the second paragraph quoted 
above (not GetSpec).  I used GetSpec in my debugging code to examine the full 
URL (thereby observing the trailing '/').
Bill, there WAS a bug regarding FTP erroneously appending slashes, but it was 
fixed over a week ago. How old is your source tree?
Assignee: rjc → law
>there WAS a bug regarding FTP erroneously appending slashes

Doh!  Then why is this bug still open?  If ftp isn't tacking on the '/' then it 
should be working.  I can't verify because the Download dialog is broken in the 
build I installed yesterday (no radio buttons).  My build is almost done and 
I'll see if it's fixed.  But it must still be broken or else you wouldn't be 
working on it.  I'm confused.

I see I worked on this early last week, while it was still broken (at least in 
my source tree).
Yep, the bug still happens. As I mentioned, as far as I see, its the URI loader
which is stripping off what it believes to be the extension, and then appends on
a new extension (in the case of the AIM Linux beta, it ends up appending
".exe").  [That's why I assigned this bug to mscott.]

I'll stop by your cube when I get in and show you a stack trace...
>Yep, the bug still happens

Depends on what you mean by "the" :-).  The *original* bug does not still 
happen, at least on (my) Windows.  But on Windows, the .rpm file does turn into 
a .exe file.

Hee hee, this is pretty funny.  The bug changed when Sarah added her comment 
here: ------- Additional Comments From S.E.V. Liberman 2000-09-06 13:37 -------

That's the *exact* same time I posted the results of my investigation into the 
original bug.  Quite the coincidence.

Subsequent discussion (as I read it now) wavered on what was actually working 
where, when but it eventually settles on what seems to be the fact that ".exe" 
is added/replaced to the file name for certain files, not that "filename.tar.gz" 
comes up as "test.exe".

As to the current remaining bug: I think this is due to the way we synthesize 
the file name based on combination of extension and mime-type.  I don't know 
exactly how it works, but it seems as if the extension and the mime-type don't 
"match" properly (e.g., ".rpm" vs. "application/octet-stream") then we try to 
impose the extension we *think* goes with the mime type.

This will vary from platform to platform, depending on what "helper apps" are 
registered.  I suspect that we should never, ever add an extension on any 
platform other than Windows (because it will be ignored anyway).

And I'm not even sure about Windows because that'll lead to weird things like 
turning .rpm into .exe.  On the other hand, the way we launch helper apps on 
Windows requires that we append the "right" extension.  So maybe we should only 
do that if we're going to launch the helper app, and not if saving to disk.

Sigh.  I'm going to have to update my tracking bug 50326, I guess.  And reassign 
this to mscott :-).  I *knew* I should have just let this slide.

Oh.  We should have listened to Peter when he tried to get us to open a new bug: 
>Let's not morph bugs. If the original steps don't reproduce the defect you're
>seeing, please open a fresh new bug report.  As written, this is WFM, though I
>can't get to the original link.

To which Robert replies:
>Peter, I don't believe this bug has morphed. I couldn't get to the first link
>either, so I tried sairuh's test case and COULD reproduce the problem.

Which I should have interpreted as "Yes, the bug has morphed, but we're going to 
keep talking about "the problem" when we're really talking about this *other* 
problem."

Maybe it's just because I'm going nuts, but I think I've got good reason for 
going nuts.
Assignee: law → mscott
Whatever.  :)

Thanks for bumping this back over to mscott where the bug belongs.
So, is the summary correct as it stands today?  It seems like this bug has
morphed to be about .rpm -> .exe rather than .tar.gz -> .exe.  Has the erroneous
appended slash been eliminated yet?
Whiteboard: se-radar → [se-radar][b3 need info]
Yes, the bug cause and symptom has changed over time.

I've changed the summary.  Please see Sarah's report on 09/06 for the problem 
that still needs attention.

The erroneous trailing '/' no longer appears on ftp urls.
Summary: File downloaded as test.exe, rather than filename.tar.gz → File downloaded as aim-1.1.41-1.i386.rpm rather than aim-1.1.41-1.i386.exe
Summary: File downloaded as aim-1.1.41-1.i386.rpm rather than aim-1.1.41-1.i386.exe → File downloaded as aim-1.1.41-1.i386.exe rather than aim-1.1.41-1.i386.rpm
So, the workaround is to just type in the extension you really want and save the
file isn't it?  Marking nsbeta3- based on that workaround.
Whiteboard: [se-radar][b3 need info] → [se-radar][nsbeta3-]
Target Milestone: --- → Future
*sigh* adding relnote3 and helpwanted.
Keywords: helpwanted, relnote3
*** Bug 48889 has been marked as a duplicate of this bug. ***
spam
Whiteboard: [se-radar][nsbeta3-] → [se-radar][nsbeta3-] relnote-user
this looks like it has been working. I have been downloading lots of good stuff
on linux build November 3.

Download any rpm from rpmfind.net to make sure.
yeah, this works now for me using linux 2000.11.21.08 trunk bits. mscott, was
there a checkin that helped this, or shall it just be marked wfm? thx!
Yes I checked something in so we no longer used the temp file name for the
suggested file name (that's where the impedence mismatch was happening with file
extensions).
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
RELNOTE Patrol:
-> xpapps 
Do we remove relnote after a bug is fixed an no longer in relnote? Might be the 
case with this bug.
Component: Networking → XP Apps
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.