Closed Bug 92158 Opened 23 years ago Closed 23 years ago

Extension for recognized filetype not added if filename is changed in save as dialog

Categories

(Core Graveyard :: File Handling, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 57113
mozilla0.9.9

People

(Reporter: madhur, Assigned: law)

References

()

Details

I downloaded today's build via Netscape 4.77

Actual: 
I tried to download the installer build from build id: 200107123 and 20010724.
I could not get the executable format of the application. I was getting the 
"type of file" as "File".

expected:
I should get the "type of file" as "Application".
Works for me.  Like a problem with 4.x browser.  Try downloading using IE or 
some other ftp app.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
I have been able to succesfully download today's build from Netscape 4.77 and 
IE. That is not the problem.

The problem i am having is --- I am unable to download from Netscape BuildID : 
20010724 and 20010723. Any reason?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The 20010724 that you mention that is not working is today's build.  You are 
saying that it does work and that it also does not work.  I'm confused.

I'm assuming that you're talking about the branch since you've provided a URL.  
That url works for me.  There is nothing wrong with downloading N6Setup.exe.  I 
also just tried downloading all of yesterday's build using 4.76.  It downloads 
fine.

You have to undersdand that this is not a Mozilla or N6 problem since the bits 
are okay on the server.  It's most likely either your network connection or your 
particular copy or 4.77.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
Madhur: please unconfuse Sean by trying to download some other random 
executable from some other server. It shouldn't matter *which* executable you 
are trying to download if downloading is broken. The installer is not involved 
in downloading the N6Setup.exe installer itself (obviously, since the 
workaround was to use a non-Mozilla browser) -- I think the choice of component 
was misleading.

You say you were trying to *download* the branch, but was the build *doing* the 
download the branch or the trunk? If the branch this might be a stop ship bug, 
expecially if it's all executables from any server as I tentatively edited the 
summary to suggest.

Changing component to Browser-General for lack of a better choice
Status: RESOLVED → REOPENED
Component: Installer → Browser-General
Resolution: WORKSFORME → ---
Summary: unable to download browser installer application from today's & yesterday's build → unable to download [executable] from today's & yesterday's build
Reassigning to Vishy, please find the right home for this potential stop ship 
bug (if it's as bad as my worst-case scenario -- it's unclear if the reporter 
is describing a trunk or branch build).
Assignee: ssu → vishy
Status: REOPENED → NEW
It is the branch build I am talking about. Sorry for not specifying earlier.

As I have mentioned that downloading today's branch build from Netscape 4.77 was 
not a problem. 

I have done some research about this and have come to a conclusion.

when I am downloading anything using today's branch build - whether it be an 
application or Image or any other software - if I change the name of the file, I 
loose the format it has to be saved in.
Say suppose -
I do a "save image as" - and in the save dialog box I change the name of the 
file from (original name) to (new name) - instead of the image file being saved 
as ".gif", it is saved as a generic file. Whereas, when I save the image file 
with it's original name - i get the appropriate file format (ie.- ".gif")

Now, similarly, is the case with the branch build application. ie. - if I save 
the installer applcation with a different name - it is saved as a generic file 
(looses it's extension), but if I save it with the original name - i am 
successful.

 I tried this on 3 different window2000 machines and I could reproduce the 
problem each time. I even did similar testing on Netscape4.77 - had *no*  
problem.

I suppose this is specific to Netscape latest builds. Not sure - but i suppose 
the problem, here, is all together different. would you say Networking?

Please look into this issue in more depth.

This does not sounds as serious as first described. Adding mscott and blake as
they have more familiarity with this code and may know whats going wrong here. 
since this seems like an internal netscape problem...
QA Contact: gemal → gbush
Not an installer issue
QA Contact: gbush → doronr
what you are describing is the way the windows file picker behaves. If you start
typing a new name the windows file picker drops the previous extension & expects
you to add an extension to your new file name. 

This isn't something we can really fix. 
Thanks for the clarification Scott. In that case, I'm marking this as invalid. 
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → INVALID
But I do not see this window file picker behaviour when i try to download/save a 
file using Netscape 4.77.
This issue is specific to Netscape 6.1
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
madhur, is this still a problem for you with either recent 0.9.4-branch or trunk
builds?
Assignee: vishy → law
Status: REOPENED → NEW
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
I'll check
Ok.... I still see a difference in behaviour when I am tring to download an 
executable using NS 6.2 vs. NS 4.77

using NS4.77 :-
==============
1. go to 
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-10-09-06-trunk/
2. click on N6Setup.exe 
3. a 'save as' dialog box appears with the the following values ---
File name = N6Setup
File Extension = All Files(*.*)
4. change the file name to say -- N6Setup_1009_06trunk 
5. click 'save'
result:- the application is automatically saved with a .exe extension. The Type 
of File = "Application"
** this is a succesful download of an executable file - no problems seen here**

Using NS 6.2 (i used today's branch build - 20011009-05-0.9.4):-
================================================================
1. go to 
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2001-10-09-09-trunk/
2. click on N6Setup.exe 
3. a 'save as' dialog box appears with the the following values ---
File name = N6Setup
File Extension = *.exe 
4. change the file name to say -- N6Setup_1009_09trunk 
5. click 'save'
result:- 
The file is saved in a generic format. The Type of File = 'FILE'. (I followed 
the exact steps to download and save the executable as I did on NS4.77). 
The saved file here should actually be getting an extension '.exe' (but this is 
not happening) , as it did in my previous scenario. Moreover - the 'save as' 
dialog box came up with a default file extension as "*.exe"  
*** This is where I am seeing the problem ******

Now, if I go ahead and do the following for step 4 in NS6.2--
a)  do not change the file name and leave it as original 'N6Setup'
OR
b)  change the file name to "N6Setup_1009_09trunk.exe" (provide the extension 
here too)
result:-
the executable file is saved with a .exe extension and i get the Type of File = 
"APPLICATION"

I should have provided these exact steps to reproduce the problem in my earlier 
comments. 
Please explain why is the 'save as' behaviour different for NS4.77 and NS6.2.

Though there is a workaround (as described above) to save files in their 
proper format (NS6.2), I still feel that this is definitely going to confuse the 
user while saving certain files. In my case it was frustrating till I found a 
workaround.

Target Milestone: --- → mozilla0.9.7
Mass moving bugs that won't get fixed this milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
I see the same kind of problem with build 2002011803 on W2K. If I change the
name of a download file in the save as-dialog, the extension (that is given in
the file type below) is not attached to the file that is written to disk. I have
checked a number of Windows applications, they all attach the extension to the
name if a file type is recognized.
Changing summary to something a little more generic...
Summary: unable to download [executable] from today's & yesterday's build → Extension for recognized filetype not added if filename is changed in save as dialog
Dup of "Filename 3-letter extension not applied when filename altered"

*** This bug has been marked as a duplicate of 57113 ***
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.