Using 2002100304, but I saw this in a previous build (about a week old) as well. Reproduce: Go to the URL, download the MacAnalysisX.dmg.gz and try to open it with "OpenUp" ... the archive is corrupted. Stuffit Exp 7 also doesn't like it. IE 5.2 can download it OK, no corruption. I've also seen this with other .gz files on VersionTracker.
-> dagley for a look
Assignee: pinkerton → sdagley
The first problem is that macanalysis.com serves .gz files as text/plain. They need to fix that.
Don't lots of places serve archive files as text/plain? StuffIt Expander usually doesn't care one way or another. I ran into this same problem with the following file: http://s.sudre.free.fr/Software/files/Euphoria.dmg.gz It downloaded fine in IE but was unusuable when downloaded with Chimera. I opened up both the IE and Chimera versions in BBEdit and they looked totally different. The Chimera version contained lots of weird text strings that didn't seem to have anything to do with what I had downloaded, like: "Why can't you see your files? This hard disk is formatted with the Mac OS Extended format. Your files and information are still on the hard disk, but you cannot access them with the version of system software you are using." and "This startup disk will not work on this computer./A Power PC based computer is required to startup/from this disk."
Those strings are part of all .dmg files. Have you contacted the server administrator about fixing their MIME setting?
I would if thier website had any contact information :) What is IE doing in this case? Ignoring the MIME type and deferring to the file extension? If so, I guess this bug is invalid (apart from evangelism issues).
What happens if you remove the .gz extension and try to mount the file as a .dmg? I'm going to venture the guess that, since it's possible to serve a gziped web page and have the browser uncompress it automagically, Chimera is decompressing the file as it's received. This is likely triggered by the text/plain type info being provided by the server.
You're right, it appears Chimera is decompressing the file before it is even downloaded. If you take the .gz off manually, it mounts fine. So I guess the question is: Is this really the desired behavoir? If so, Chimera needs to strip the .gz extension off at some point before the file is downloaded.
firstname.lastname@example.org, you could try e-mailing email@example.com, or check for an administrative contact in the domain's WHOIS information.
Darin: do we decompress .gz on the fly? Or is this a server thing?
does chimera implement its own helper app support or something? the problem is that a server (such as apache) will send a content-encoding: gzip header for any document served up with a .gz extension. this header indicates that the content of a HTTP message should be decompressed before being passed off to a viewer. however, we know that this is not always the right thing. specifically, if the document is going to be save and it has a .gz extension, we probably want to preserve the compression. the mozilla helper app mechanism explicitly checks for these sort of things and calls nsIHttpChannel::SetApplyConversion(PR_FALSE) if it wants to avoid decompression. bz would be able to provide more details.
Well.. if Chimera uses Mozilla's ExternalHelperAppService, then we explicitly check for the .gz extension and do not decompress if it is present (see the code in nsExternalAppHandler::OnStartRequest and nsExternalHelperAppService::ApplyDecodingForExtension). If Chimera's rolling its own unknown content type handler, then they have to do something like that (and if you decide to do this, please don't copy the broken logic in nsExternalAppHandler; let me know and I'll describe what the logic really _should_ be (especially if you get to make this decision _after_ the user has selected what to do).
How is the file being saved? By clicking and getting the Save As dialog or doing a control-click and selecting Download Link Target? There's 2 seperate code paths involved in those.
http://www.geektools.com/cgi-bin/proxy.cgi is the perfect tool to find any ALL site automatically, no need to change the Server popup. versiontracker.com: firstname.lastname@example.org AND email@example.com free.fr: firstname.lastname@example.org AND email@example.com WorksForMe using Build 20021018 - OS X 10.1.5 using Download Link Target of course.
Still broken for me regardless of whether I do Download Link Target or Save As... (2002101804)
Remember that Versiontracker doesn't host the files. You have to contact the individual developerss about their server.
Steve's hack fixes both of the examples for me in the 2002102704 build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified in the 2002-11-12-04 NB under 10.2.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.