Closed Bug 396477 Opened 16 years ago Closed 16 years ago

DM renames many files with double extension, e.g. filename.exe.exe

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9beta1

People

(Reporter: By-Tor, Assigned: Mardak)

References

Details

(Keywords: regression)

Attachments

(2 files)

Downloaded file renamed and with double extension
2.65 KB, image/png
Details
v1
1.01 KB, patch
sdwilsh
: review+
mconnor
: approval1.9+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091705 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091705 Minefield/3.0a8pre

Since the landing of Bug 395308 executable files are renamed with a dual extension, .exe.exe.  Other file types seem unaffected.

Reproducible: Always

Steps to Reproduce:
1. download .exe file
2.
3.
Actual Results:  
.exe file is renamed filename.exe.exe

Expected Results:  
File should be saved as original file name.
Keywords: regression
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Download Manager → File Handling
Product: Firefox → Core
QA Contact: download.manager → file-handling
Flags: blocking1.9?
This also happens with other file types, at least under Windows.
To make things even worse: If you try to save a file overwriting an existing file with the same name, Firefox asks if the existing file should be replaced but instead, the downloaded file is renamed and it is given the double extension. See my attachment (Screenshot).
Summary: DM renames executable files with double extension, i.e. filename.exe.exe → DM renames many files with double extension, i.e. filename.exe.exe
Assignee: nobody → comrade693+bmo
Target Milestone: --- → mozilla1.9 M9
Summary: DM renames many files with double extension, i.e. filename.exe.exe → DM renames many files with double extension, e.g. filename.exe.exe
Still present under Vista and Vista SP1 on 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007091904 Minefield/3.0a8pre
Flags: in-litmus?
Just to clarify - is this windows only?  If so, I think I see what *may* be the problem, but I'm not 100% sure still.

For my reference:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.345#2096
Looks like it is windows only since I cannot reproduce this on my mac.
What other bugs landed in this window?  I'm not really sure if Bug 395308 actually caused this...
Keywords: qawanted
Keywords: qawanted
It's present on Linux. Happened a few times for me. I just downloaded a gzip archive and ended up with .tar.gz.gz. Interestingly, it also appends .exe to any binary file -- for example, .iso.exe.
I'm seeing something odd here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileOS2.cpp&rev=1.96&root=/cvsroot#2167

There once was a return there, maybe that's the culprit. If I'm correct, this file is not only about OS/2 filename stuff?
This is about in general, though I haven't been able to reproduce it on the mac (I haven't tried a tar.gz file however).
Definitely regressed with bug 395308 because now tempFile.isExecutable() doesn't work.
Assignee: comrade693+bmo → nobody
Component: File Handling → Download Manager
Flags: blocking1.9?
Product: Core → Firefox
QA Contact: file-handling → download.manager
Target Milestone: mozilla1.9 M9 → Firefox 3 M9
Attached patch v1 — — Splinter Review 
Don't use this.mLauncher.targetFile.isExecutable because it'll give us the wrong information.

Append the primary extension only if it doesn't already have it.
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #283067 - Flags: review?(comrade693+bmo)
Flags: blocking-firefox3?
Comment on attachment 283067 [details] [diff] [review]
v1

r=sdwilsh
Attachment #283067 - Flags: review?(comrade693+bmo)
Attachment #283067 - Flags: review+
Attachment #283067 - Flags: approval1.9?
Testing with WinXP Pro SP2, with Mardak test build. As far as I can tell, it's fixed.
Attachment #283067 - Flags: approval1.9? → approval1.9+
Checking in toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in;
/cvsroot/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in,v  <--  nsHelperAppDlg.js.in
new revision: 1.54; previous revision: 1.53
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
Seems to break double extension file downloading.

Try to download firefox-3.0a9pre.en-US.linux-i686.tar.bz2 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

And you'll get this in error console :

Error: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.primaryExtension]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js :: anonymous :: line 219"  data: no]
Source File: file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js
Line: 219

Reopening and backing out the patch could be a good idea ? Because it is a big regression :(
WFM with 2007100304 and 2007100405

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Minefield/3.0a9pre
Blocks: 398551
(In reply to comment #18)
> Error: [Exception... "Component returned failure code: 0xc1f30001
> (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.primaryExtension]"  nsresult:
> "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
> file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js ::
> anonymous :: line 219"  data: no]
> Source File:
> file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js
> Line: 219
This error is garbage and is safe to ignore (see bug 393627).
But the problem stays the same. I CANNOT donwload any file ending with tar.bz2 or tar.gz :(
I'm assuming you're running linux? WFM Windows and Mac OS X -- I can't get trunk running on Linux.
sdwilsh: that isn't the handlerservice error...
I've seen that since that code landed - I was under the impression that it was the same cause...
Erh... I thought it was related to gcc 4.2 under Gutsy AMD64.

But with gcc 4.1, same problem. No file could be downloaded if it is ended like tar.bz2 / tar.gz.

Could be a AMD64 bug ?!
sdwilsh: You can't assume that a mime info has a primary extension
Sorry to say that reversing the patch makes downloading working fully and completely again.

Strange !
Frederic: Can you confirm that you're running firefox on linux -- and would you happen to be saving to a mounted drive that has the executable bit incorrectly set? (Or perhaps your umask has things created with executable set.)

biesi: If we can't grab the primary extension, we should probably still try putting on some extension to prevent the user from accidentally creating an executable? E.g., saving a .torrent file as .exe. But then what extension should we use if we couldn't get the primary extension? Take the source's?

And I suppose we could make this Windows only for bug 270159.
I am using Ubuntu Gutsy Gibbon AMD64.

$ uname -a
Linux fredo-gutsy 2.6.22-12-generic #1 SMP Sun Sep 23 20:03:18 GMT 2007 x86_64 GNU/Linux

I want to save every single download on my main partition, in a directory named download.

Here are the sets of my download directory :

$ ls -al download
total 12
drwxr-xr-x  2 fred fred 4096 2007-10-04 21:06 .
drwxr-xr-x 50 fred fred 4096 2007-10-05 10:22 ..
-rw-r--r--  1 fred fred 1039 2007-10-04 19:59 exe.exe.patch
Depends on: 398917
I'm confused; is it safe to verify this, since it's now working fine on Windows using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101905 Minefield/3.0a9pre, (and do we need to then spin off a bug for comment 29 and others), or are we going to address Frederic's issues here?
(In reply to comment #30)
> I'm confused; is it safe to verify this, since it's now working fine on Windows
> using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre)
> Gecko/2007101905 Minefield/3.0a9pre, (and do we need to then spin off a bug for
> comment 29 and others), or are we going to address Frederic's issues here?
He needs to file a different bug if he didn't already.  This bug can be verified.
Verified FIXED on Windows Vista; see comment 30.
Status: RESOLVED → VERIFIED
This bug is fixed, mine is 398551. And it is kinda pain-in-the-*** to say the least :(
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.