89064 - osx - File Download doesnt accept complete filenames

Status: VERIFIED DUPLICATE of bug 95481

(Core Graveyard :: File Handling, defect)

Description

[Jimmy Sieben]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2) Gecko/20010702
BuildID:    20010702

Go to http://www.apple.com/downloads/macosx/networking/ and try to download
Sharity. The file is named .......dmg.gz however, the file download function
cuts this filename off, leaving .......dm

The expected behavior is for File Download to accept filenames of any length, or
at least long enough to download files with names this long, as I don't think
this is too terribly uncommon.

Tested on OSX with Mozilla 0.9.2 

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.apple.com/downloads/macosx/networking/
2. Click on Sharity to download it
3. Note that the filename does not match what the server sent

Actual Results:  Mozilla cut the end of the filename off

Expected Results:  Mozilla should have accepted the full filename, or let me
rename it to be the full filename

Comment 1

[James Paige]

That is happening only because it is a .gz file

see bug 35956 for details

Comment 2

[benc]

That bug is fixed. I think there is a differnt bug about that.

-> xp apps?

Comment 3

[Chris Petersen]

Confirming problem under Mac OS X with July 3rd Fizzilla build.

Comment 4

[Adam Masri]

Platform: PowerBook G3/300/192Mb/25Gb, MacOS X 10.0.4
Fizzilla Build: 2001070318

I noticed that the truncated filename length is 31 characters. This was the old
filename limit before OS X, and I believe it's a carryover to Carbon. I took a
quick look at the Navigation Services for Carbon info.

http://developer.apple.com/techpubs/macosx/Carbon/Files/NavigationServices/navigationservices.html

Since Carbonized Nav Services support a lot of the HFS+ extensions that OS 9
didn't, I'm hoping it'll be possible to support long filenames in OS X with
Fizzilla.

- Adam

Comment 5

[Doug Turner (:dougt)]

necko does nothing with file names.  clients provide this to us.  over to law
for investigation.

Comment 6

[Bill Law]

I strongly suspect that our nsIFile/nsILocalFile/nsILocalFileMac/nsIFilePicker
code is imposing this 31-char limit, either directly or indirectly (because of
the Mac system calls we're doing).

I'm going to pawn this off on Paul Chen since it's definitely a Mac-specific
thing and he'e better able to diagnose and fix those.

Comment 7

[Steve Dagley]

*** Bug 101233 has been marked as a duplicate of this bug. ***

Comment 8

[Paul Chen]

-> pinkerton!

Comment 9

[Mike Pinkerton (not reading bugmail)]

over to conrad, who was working on something similar.

Comment 10

[J Luh]

Mozilla on OS X should at least preserve the filename extension, and preferably
should preserve the whole filename.

Comment 11

[Conrad Carlen (not reading bugmail)]

While not a dup, this will be fixed with bug 95481. Using the new Unicode file
APIs available with HFS+, you get support for long file names.

Comment 12

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 13

[Steve Dagley]

This is on the list of bugs needed to make MachV a good Mac OS X citizen so
adding  nsbeta1 keyword

Comment 14

[Conrad Carlen (not reading bugmail)]

While not exactly a dup, will be fixed by bug 95481. Marking dup to get off
nsbeta1 radar. Bug 95481 is on the radar.

*** This bug has been marked as a duplicate of 95481 ***

Comment 15

[Tom Everingham]

marking verified per ccarlens comment