Closed Bug 50420 Opened 25 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.