Large parts and Windows X64

Jan 8, 2013 at 3:12 PM

I have rebuilt libopc on Windows (VS2010) for X64 platform (I think!). It certainly is running in a 64-bit executable. However, I see that the part headers in zip.c appear to be hard-coded as unsigned int 32:

 && (4==opcZipRawWriteU32(io, rawState, compressed_size))  // compressed size
        && (4==opcZipRawWriteU32(io, rawState, uncompressed_size))  // uncompressed size

 

As expected, when I create a large part (12391552489), the recorded archive compressed size  (3801617899) is incorrect, and is exactly the remainder of the original size modulo max unsigned int32:

12391552489%4294967295

=

3801617899

 Now, Winzip knows the actual size of the uncompressed part, so I believe the deflated stream is written correctly, but the header is incorrect.

Have I built the X64 target incorrectly or is this a libopc limitation? I suspect the latter because of the 4 byte write quoted from zip.c, above.

Jan 8, 2013 at 5:18 PM

 

Well, duh, now that I submitted this, I see that Zip64 is not currently supported and there is an existing work item to add Zip64 support. The field set in the quoted code is the original zip header, for file sizes up to 0xFFFFFFFF.  I just voted the work item up. Any comments on the difficulty of accomplishing this?