BinHex downloading shows uncompressed transferred but compressed total on !mac




16 years ago
10 months ago


(Reporter: Jesse Houwing, Unassigned)


(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-would-take], URL)


(1 obsolete attachment)



16 years ago
BuildID:    2002080208

Click the download now link at the bottom.

Mozilla downloads only 750 kb of the 1000 kb there is.

Afte a while it comes up with a "interrupted system call" error message

Reproducible: Always

Comment 1

16 years ago
wfm using build 20020811 on Linux (trunk).
related: bug bug 148813.

Comment 2

16 years ago
I can duplicate the problem on Windows XP with build 2002080908. I did not see
an "interrupted system call" message, but the download manager shows 1048KB
downloaded and the file size is only 741K. I also saw unusual Kanji characters
on that page, which may or may not be related. (screenshot attached)

The download works fine on Mac OS X with build 2002081103, and no weird Kanji.

Comment 3

16 years ago
Created attachment 94839 [details]
Screenshot of page, showing weird kanji

Comment 4

16 years ago
IE, NS4.7 and opera do download the file completely with the same proxy
settings, also disabling proxy has no effect.

Comment 5

16 years ago
Just entered the actual URL of the file (which is ) and I still get a truncated
file. So it has nothing to do with the kanji.

Comment 6

16 years ago
Comment on attachment 94839 [details]
Screenshot of page, showing weird kanji

So it's probably unrelated to the kanji. I filed that as a separate bug
Attachment #94839 - Attachment is obsolete: true

Comment 7

16 years ago
I think this might be because of the BinHex encoding. if the file is 1072kB on
the server, but the uncompressed file is 7XX, and mozilla uncompresses it while
it downloads it or something.

Comment 8

16 years ago
But it's from an FTP site, so it should leave the file alone, no content
encoding to worry abount and such.

Comment 9

16 years ago
urm, check for yourself.
first I downloaded it with moz. get a file of 7XXkB. head it.. lots of
unreadable stuff.
then I wget the same file. head that.. wow, this is actually readable, says it
is bin-hex encoded and all.

Comment 10

16 years ago
Save target as gives 1048 Kb, Save as or just clicking gives 740 kb.

Seems indeed that Mozilla does something like unpacking it. But it should not.
The file is binhexed on the ftp server, and should transfer and be saved that way.

If it were on a HTTP server AND transfer-encoding would have been set, THEN it
should unhex it and save the decoded file.

Comment 11

16 years ago
copypasting from nsBinHexDecoder.h :

// This decoder is currently only intended to be used on NON-Mac platforms. It
isn't hooked up to 
// code which would actually save the file to disk. As a result, we can't
leverage the resource fork.
// This makes this decoder most unhelpful for the Mac. Our assumption is that if
you save a bin hex file
// on the mac and try to open it, stuffit or some other tool is already going to
be on the Mac which knows how
// to handle bin hex. On windows and unix, that's not the case. We need client
code to strip out the data fork. 
// So this decoder currently just strips out the data fork.

meaning, the bug is probably invalid, or you have to change the summary.

Comment 12

16 years ago
probably a bug, though. IMHO, it should display 1048/1048 kbytes transfered,
even if the saved file is 740 kbyte. (since 1048 kbytes _were_ transfered)

Comment 13

16 years ago
But it is a FTP transfer, so nothing should be unbinhexed.

I want to put this file on a floppy and get it to my mac (which has no internet)
and it wants the resource data in the binhexed file.

Maybe mozilla should pop-up and say, hey this file has been binhexed. I can
unpack it for you if you want to. Do you want that?

[yes] [no]

Comment 14

16 years ago
ccing mscott to get some expert advise. (author of nsBinHexDecoder)
os,platform -> all.. (this is really all except mac os)
and changing summary.
OS: Windows 2000 → All
Hardware: PC → All
Summary: File downloads only partially, but is reported to go succesfully. → BinHex downloading shows uncompressed transfered but compressed total on !mac


16 years ago
Summary: BinHex downloading shows uncompressed transfered but compressed total on !mac → BinHex downloading shows uncompressed transferred but compressed total on !mac

Comment 15

16 years ago
-> file handling
Assignee: new-network-bugs → law
Component: Networking → File Handling
QA Contact: benc → sairuh
The unbinhexing code happens in the uriloader way before the file handling code
ever kicks in... in fact, it happens before we've decided whether we will be
file handling or not.

The fact that unbinhexing happens at all is a necko architecture bug... the
stream converters get hooked into place no matter what and there's no API to
disable them after the fact or anything like that...

I suppose we could disable converters entirely for ftp:// content (bad idea,
imo).... or we could mark some converters as not applicable to some protocols
(not sure of this one).

So what's the bug here?  The incorrect numbers are file handling, the fact that
unbinhexing happens is necko.  decide, please?  Or file a separate bug on one of
those issues?
Component: File Handling → Networking

Comment 17

16 years ago
> The incorrect numbers are file handling,

That's what the summary says so I guess that's what this bug is about. -> file
handling. (if anyone disagrees, open a new bug for not unbinhexing automatically.)
Component: Networking → File Handling
Taking.  I know how to fix this, except HTTP channels don't allow setting
content-length.  This is all necko all the way after all..
Assignee: law → bzbarsky
Component: File Handling → Networking
Depends on: 167887
Priority: -- → P4
QA Contact: sairuh → benc
Target Milestone: --- → Future

Comment 19

16 years ago
I found another case where the size in the downlaod manager does not match the
actual file size.


and select all the functions in the lest field and ">" them to the right one.

Now set a filename (cflib or something) and select "file"

generate the libary. It takes quite a while...

the downlaod in the downlaod menager shows at least 450 Kb and then suddenly
drops back to 1kb and finishes up. This seems wrong. It is close to this bug,
but it could be something completely different. If so, I'll open up a new one.
It's probably related. Likely gzip encoding instead of binhex. Please file a
separate bug and mark it as depending on this one, ok?  gzip would be harder,
since it does not know the filesize up-front, necessarily... at least bihex does.

Comment 21

15 years ago
A file is silently un-binhexed, then saved WITH the hqx extension.

FTR, I would prefer that files never be automatically
darin, would it be at all possible to expose a content-length setter?

Comment 23

14 years ago
Is Bug 236773 a dupe of this?
That bug is about the fact that the unbinhexing is done, basically....  This bug
is about deciding whether to do it and if so how best to.  Not quite a dup.
Blocks: 236773

Comment 25

14 years ago
(In reply to comment #22)
> darin, would it be at all possible to expose a content-length setter?

bz: nsIChannel::SetContentLength exists, but I'm guessing that more is needed??

Comment 27

14 years ago
bz: how would implementing SetContentLength help solve this bug?
The binhex decoder could set the content length to the length the data will be
when decoded, so that we wouldn't have this situation where we're showing the
total based on the number of bytes on the wire and the progress based on the
number of bytes on disk...

Comment 29

13 years ago
I've filed bug 305977 to explicitly request that automatic de-BinHexing not be
done on non-Mac platforms, as mentioned in some of the comments here.
Assignee: bzbarsky → nobody
Priority: P4 → --
Target Milestone: Future → ---
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.