Closed Bug 181029 Opened 22 years ago Closed 13 years ago

Don't add an extension to a download if one is not present, just set the HFS code on the downloaded file.

Categories

(Camino Graveyard :: Downloading, defect)

Product:
Camino Graveyard
Component:
Downloading
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: sbwoodside, Assigned: nick.kreeger)

References

(
URL
)

Details

Attachments

(1 file)

Proposed patch
1.25 KB, patch
Details | Diff | Splinter Review 
2002111604. On the linked page, there is a link to download "ltconfig"
(http://fink.sourceforge.net/files/ltconfig) when I option-click on the file to
download it, chimera adds ".txt" to the end of the file. Correct behaviour is to
leave the file name alone, it should be properly ltconfig with no extension.
The file is served as text/plain. Now that Apple is phasing out type codes, the
way to indicate the file type is the name extension. The name extension
equivalent of text/plain is .txt, so Camino is applying the right mapping from
HTTP Content-Type to file name extensions.
taking
Assignee: sdagley → josha
I don't agree with comment #1. The right thing to do is to let the file
extension rule the day, but that doesn't mean we have to add it. We ought to
save the file as it is named, and if there is no extension there is no
extension. I don't agree with using MIME to set type/creator codes (except for
the fact that classic Finder didn't behave nicely otherwise), and I don't agree
with using it to set file extensions either. Let the Finder figure out how to
handle it - that way the users's preferences are respected, we don't end up
doing the wrong thing ever, and the intentions of the person who posted the file
named as such are respected.
And for the record, its worse now - now we're adding .asc to the file from the
bug description (http://fink.sourceforge.net/files/ltconfig).
I think we should not play the wise kid and give files an extension when the
original file doesn't have one. we should always respect the authors file
extension even if it doesn't have one. Especially since no harm can be done.

Right now we are guessing and making mistakes. Which is not OK.

Safari is respecting the lack of file extensions as well as always respecting
the original file extension. So I agree with Josh when he says; "Let the Finder
figure out how to handle it - that way the users's preferences are respected, we
don't end up doing the wrong thing ever, and the intentions of the person who
posted the file named as such are respected."
Bug 181727 is heretical to this one...
Camino should append the extension, but also *hide* it.
As far as I know Camino isn't able to hide an extension the Finder does that for
you. So both cases the Finder should do all the work.
Greg - why do you think the behavior you suggested is the right way to do things?

Repeating comment here:

Saving the file is Camino's job. Opening the file is the Finder/users's
job. Its our job to save the file as its posted - filename and all. Screwing
with the extension is like MS Word's "helpful hints" for your save panel. Here's
a quote from Apple's HIG:

"When opening and saving a document file, applications ... should preserve the
existing filename extension unless the user creates a new document file by
choosing Save As"

So - we end up tacking on ridiculous extensions quite often, and we're going
against HIG to boot. See bug 181029 for more info.
Status update? This seems like something that should be fixed pre-1.0. Maybe
even for 0.9?
Target Milestone: --- → Camino1.0
Not a 1.0 blocker, though it'd be nice to have.

CCing Wevah and targeting for 1.1.
Target Milestone: Camino1.0 → Camino1.1
Updating summary.
Summary: chimera adds .txt to a file without being asked → File Extension (.txt) added to a file without being asked
I wonder if this is behind the problem users have reported with RealPlayer not
launching when downloading these .ram files:
http://forum.wgbh.org/wgbh/forum.php?lecture_id=1824
(Camino saves them as ram.php, Safari as ram.ram)
taking..
-> kreeger
Assignee: joshmoz → nick.kreeger
This appears to be more necko regression. This test works just fine in Firefox
1.0.6, but in Deer Park Alpha 2, the action is simular to our own problem,
except instead of forcing a .txt extension, a .html extension is added in Deer
Park Alpha 2. Could be another core issue.
Testing inside the new firefox beta 1, it appears that .html gets added on still
if option clicked. While in Camino 1.0a1, we show the save dialog rather than
directly downloading. Maybe an update to this bug, or is option-clicking
disabled for a purpose?
(In reply to comment #17)
> Maybe an update to this bug, or is option-clicking disabled for a purpose?

Showing the save dialogue instead of simply downloaded in opt-click is bug 219056.
QA Contact: chrispetersen → downloading
Target Milestone: Camino1.1 → Camino1.2
Attached patch Proposed patch — — Splinter Review 
Proposed solution is to not append a file extension for a MIME content of type "text/plain". Simon could you please take a look?
Attachment #222275 - Flags: review?(sfraser_bugs)
Why is text/plain special?
I'd guess because it's often the default type for file extensions that aren't mapped to any other type.
Doing some more experiements on other browsers using our test case (http://fink.sourceforge.net/files/ltconfig), I have found this:

Safari on the latest 10.4 -> appends the .sh, and asks if the script should be run
Safari on 10.3.9 -> Saves the file without an extension
Firefox 1.5.0.3 - > Appends a .htm to the file
IE 7 Beta 2 -> Appends a .txt file

Should this bug depend on some core mime bug or is this a case where we want to sniff out a plain/text file and save it as it is named?
[2:19pm] ardissone: it seems to me that what we want to do here is 1) see if the original file has an extension
[2:19pm] ardissone: a) if so, use that extension
[2:20pm] ardissone: b) if not, don't add an extension, but check the MIME type and set the HFS type code that's appropriate (if any)
...
[2:30pm] ardissone: the only place where it's appropriate for us to ever add/change an extension is saving as HTML Complete or "Save as Text", since in both of those cases we're coercing the type of document on user request

So a jpeg served as image/jpeg at url someurl.com/myjpeg would be saved as "myjpeg" with HFS type JPEG (no creator); a text file served as text/plain at url someurl.com/myfile would be saved as "myfile" with HFS type code TEXT (no creator).

Doing that would solve the problem with this file (the user has to rename the file before it can be used) while at the same time keep all odd files like this openable without additional user interaction (provided the server is serving the files with the correct MIME type)--i.e., we'd still make files in comment 13 be openable, since it's served with the right MIME type). This is a compromise between our current behavior and what Josh argues in comment 3.
Summary: File Extension (.txt) added to a file without being asked → Don't add an extension to a download if one is not present, just set the HFS code on the downloaded file.
Nick, any progress on this, especially as regards a patch along the lines of comment 23?
Comment on attachment 222275 [details] [diff] [review]
Proposed patch

Clearing this old request since this patch isn't doing what we want (comment 23).
Attachment #222275 - Flags: review?(sfraser_bugs)
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Given Core has ripped out support for adding type codes (it used to do it for us), and type codes are rapidly dying, the best we can do now is let users change/remove the suggested extension for weird/extensionless files, which is what bug 583818 allowed us to do again.

Given those realities, this is, sadly, a WONTFIX.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: