Appears to be a 2Gbyte limit on blob slicing/storage Mac OS X Snow Leopard

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create the testfile as specified in the HTML page enclosed
2. Click on the links in the HTML page, running the javascript to exercise
Gears blob slicing and storage
3. Compare the data in the localstore's files with the expected values

What is the expected output? What do you see instead?

The expected output is that the relevant slices of the source file will be
stored in the local store's files. 

The actual output is that the stored blob slices starting at of beyond
2**31 are either stored as zero bytes, or appear to be another part of the
file from that expected.

What version of the product are you using? On what operating system?

* Mac OS X 10.6.1
* Firefox 3.5.3 (build date: 20090824)
* Google Gears 0.5.32.0
* Running on MacBook5,2 with 2 Gbytes RAM

Please provide any additional information below.

Although this fails to work properly with the configuration above, it seems
to work fine on Windows XP with both Firefox 3.5.3 and Internet Explorer 8.

Original issue reported on code.google.com by n...@mediachannel.ltd.uk on 19 Oct 2009 at 4:15

Attachments:

• testcase_localstore.html

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

See also Issue 958: "Appears to be a 2Gbyte limit on blob upload on Mac OS X 
Snow
Leopard", which I believe is likely to be closely related to this one.

This issue needs to be tested on Leopard to see if the same problem is 
experienced there.

Original comment by n...@mediachannel.ltd.uk on 19 Oct 2009 at 4:39

[GoogleCodeExporter]

Note that these are _silent_ failures, with no error message generated, which 
made
them doubly frustrating to track down.

Original comment by n...@mediachannel.ltd.uk on 19 Oct 2009 at 4:41

[GoogleCodeExporter]

This also does not work on Leopard, with firefox

Original comment by ben.roe...@gmail.com on 19 Oct 2009 at 4:46

[GoogleCodeExporter]

I haven't had a chance to double-check, but based on a bit more poking around, 
I'd
guess that offsets between  approx 2**31 and approx 2**32 are probably being 
treated
as negative, and lead to the zeroed files, and that offsets > 2**32 are being 
wrapped
round to values ~4G smaller by 32-bit truncation.

All of this is consistent with a 32-bit signed integer being used somewhere, 
but I
have no idea where it might be. 

Original comment by n...@mediachannel.ltd.uk on 19 Oct 2009 at 5:05