162171 - BinHex downloading shows uncompressed transferred but compressed total on !mac

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect, P5)

Description

[Jesse Houwing]

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

[Olivier Cahagne]

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

Comment 2

[Nathan Silva]

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

[Nathan Silva]

Attachment: Screenshot of page, showing weird kanji

Comment 4

[Jesse Houwing]

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

Comment 5

[Jesse Houwing]

Just entered the actual URL of the file (which is
ftp://ftp.hp.com/pub/scanners/software/sj185en.hqx ) and I still get a truncated
file. So it has nothing to do with the kanji.

Comment 6

[Nathan Silva]

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
#162182.

Comment 7

[alge]

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

[Jesse Houwing]

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

Comment 9

[alge]

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

[Jesse Houwing]

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

[alge]

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

[alge]

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

[Jesse Houwing]

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

[alge]

ccing mscott to get some expert advise. (author of nsBinHexDecoder)
os,platform -> all.. (this is really all except mac os)
and changing summary.

Comment 15

[benc]

-> file handling

Comment 16

[Boris Zbarsky [:bzbarsky]]

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?

Comment 17

[alge]

> 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.)

Comment 18

[Boris Zbarsky [:bzbarsky]]

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..

Comment 19

[Jesse Houwing]

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

Open

http://www.cflib.org/LibraryGenerator.cfm

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.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

[Ken Takusagawa]

A file is silently un-binhexed, then saved WITH the hqx extension.
(linux)

FTR, I would prefer that files never be automatically
un-binhexed.

Comment 22

[Boris Zbarsky [:bzbarsky]]

darin, would it be at all possible to expose a content-length setter?

Comment 23

[Bob Clary [:bc] (inactive)]

Is Bug 236773 a dupe of this?

Comment 24

[Boris Zbarsky [:bzbarsky]]

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.

Comment 25

[Darin Fisher]

(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 26

[Boris Zbarsky [:bzbarsky]]

Darin, see
http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#2954
 -- last I asked you, you were opposed to implementing that method...

Comment 27

[Darin Fisher]

bz: how would implementing SetContentLength help solve this bug?

Comment 28

[Boris Zbarsky [:bzbarsky]]

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

[Justin Kerk]

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.

Comment 30

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 31

[Andrei Purice]

Marking this as Resolved > Incomplete since the provided url isn't working anymore and the last relevant activity on this issue was 17 years ago.
If anyone can still reproduce this issue please re-open this ticket or file a new one with more details on how to reproduce it.

Comment 32

[Boris Zbarsky [:bzbarsky]]

The binhex decoder was removed a long time ago, so this exact issue can no longer happen.