Chimera corrupts dmg.gz files

VERIFIED FIXED in Chimera0.6

Status

Camino Graveyard
Downloading
--
critical
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: S Woodside, Assigned: Steve Dagley)

Tracking

unspecified
Chimera0.6
PowerPC
Mac OS X

Details

(URL)

(Reporter)

Description

16 years ago
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

Comment 2

16 years ago
The first problem is that macanalysis.com serves .gz files as text/plain. They
need to fix that.

Comment 3

16 years ago
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."

Comment 4

16 years ago
Those strings are part of all .dmg files.

Have you contacted the server administrator about fixing their MIME setting?

Updated

16 years ago
Target Milestone: --- → Chimera0.6

Comment 5

16 years ago
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).
(Assignee)

Comment 6

16 years ago
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.

Comment 7

16 years ago
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.

Comment 8

16 years ago
kaldari@onyxsys.net, you could try e-mailing webmaster@macanalysis.com, or check
for an administrative contact in the domain's WHOIS information.

Comment 9

16 years ago
Darin: do we decompress .gz on the fly? Or is this a server thing?

Comment 10

16 years ago
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).
(Assignee)

Comment 12

16 years ago
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.

Comment 13

16 years ago
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:
webmaster@techtracker.com AND dgilbert@techtracker.com

free.fr:
nhyvernat@corp.free.fr AND hostmaster@proxad.net

WorksForMe using Build 20021018 - OS X 10.1.5
using Download Link Target of course.

Comment 14

16 years ago
Still broken for me regardless of whether I do Download Link Target or Save
As... (2002101804)

Comment 15

16 years ago
Remember that Versiontracker doesn't host the files. You have to contact the
individual developerss about their server.

Comment 16

16 years ago
Steve's hack fixes both of the examples for me in the 2002102704 build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 17

16 years ago
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.