216043 - File size displayed in downloading ("Saving") status box is signed/sign-extended.

Status: RESOLVED DUPLICATE of bug 228968

(SeaMonkey :: Download & File Handling, defect)

Description

[Cyrus Patel]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD 5.0; en-US; rv:1.4b;) Gecko/20030612
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD 5.0; en-US; rv:1.4b;) Gecko/20030612

Filesizes displayed in the "Saving" status box are a) signed, b) sign-extended

http://fb14.uni-mainz.de/~cyp/moz/dl_rema.gif is a screen shot of this.
The size of the file being retrieved is actually 4122357489 bytes.

Converted to KB that would be... 4025740 KB == 0x003D6D8C
Mozilla displays that as ...     -168563 KB == 0xFFFD6D8D

Looks like a sign'edness bug to me.



Reproducible: Always

Steps to Reproduce:
1. Create a big file (on an ftp server)
2. Retrieve it using mozilla. 
3. Watch the numbers.

Comment 1

[Jon Henry]

-> Download manager

I don't have such a giant file personally to test with (is there any chance you
could temporarily link to one?), but based on the screenshot I'll confirm this.

Comment 2

[Cyrus Patel]

I don't have a public server where I could put a file of that size, but...

there is a utility (unistd source plus win32 source+binary) at
http://fb14.uni-mainz.de/~cyp/moz/dl_rema/chsize.zip which will
let you quickly create a (sparse) file of any size.

Comment 3

[Jon Henry]

Attachment: Screenshot of problem

That's a very handy utility, thanks for pointing it out. I can now confirm this
bug on Win2000 in the 20031028 trunk build. I created a 5GB file using the
provided utility, and then tried to save a copy using Mozilla. After
approximately the 4GB barrier, the signs and values went haywire.

Note that bug 198833 may be related, however it doesn't seem to be related to
file size.

Comment 4

[Cyrus Patel]

well, irrespective of the algorithm used to compute time remaining, there will
always be a dependancy on file size. 

In other words, if file size is being _computed/stored_ incorrectly (and not
just being _displayed_ incorrectly), then bug 198833 is almost certainly related.

Comment 5

[Cyrus Patel]

on the other hand, I couldn't reproduce that bug in five tries (but 
http://bugzilla.mozilla.org/show_bug.cgi?id=198833#c7 states "its not very 
reproducible", so it may just be my luck).

Comment 6

[Stian Oksavik]

Attachment: Download size and speed overflow

I ran into this one today with FireFox 0.9.3 under Windows XP SP2. Attaching an
additional screenshot; in my case, the time remaining counter also seems to
have overflowed. The file being downloaded was the Fedora Core 2 DVD ISO from
http://fedora.redhat.com/ (in case anyone still has trouble reproducing this.)

-Stian

Comment 7

[Stian Oksavik]

Comment on attachment 156042 [details]
Download size and speed overflow

In my case, the download speed seems to have overflowed as well. Seems to me
all of these numbers should be stored in unsigned longs; even then, there could
be a problem with truly humongous files.

Comment 8

[Steven C.T. Cook]

This is still an issue in: "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0" running on Windows 98SE and Windows 2000.

I was monitoring the download of Blizzard's World of Warcraft Beta Client (2.5
GB), and noticed the displayed file size went negative right at the 2GB mark
(indicating a signed 32-bit integer being used, instead of an unsigned 32 (or
better, 64) bit integer).

This issue should exhibit with any file > 2147483648 bytes.

Comment 9

[Randy Groves]

*** Bug 280064 has been marked as a duplicate of this bug. ***

Comment 10

[OstGote!]

For me this looks like a clear duplicate of the well-known bug 228968. 
See Bug 184452 for all the other problems with the 2/4 GB limit.

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614