s.Position carries too large value for int type

Nov 16, 2008 at 12:51 PM
Hi there,
I had today several IOExceptions because a file pointer was about to be set before the beginning of the file. After I hooked up to the project and started debugging it turned out that _RelativeOffsetOfHEader was like a very large number in minus (-243....bla bla cannot remember the exact value). I traced it back and found that the assignment of that value is in line 2079 in ZipEntry.cs and the s.Position value turned out to be 2147498647 which is larger than the allowed value for int. So I tried using Int64 as a type for _RelativeOffsetOfHeader (and also changed all assignments of that value to Int64) and it seemed to have worked.

What do you think?
Nov 16, 2008 at 2:58 PM
Hey Mozzy
Yes you are correct, s.Position is a long (64 bits), not an int (32 bits).
As a result there is the chance that there will be problems.
The zip file spec allows for 64bit quantities for these things, in the zip64 spec.  I did not implement zip64 in the library yet.
There is a workitem for zip64 support. http://www.codeplex.com/DotNetZip/WorkItem/View.aspx?WorkItemId=6437
If you feel strongly about it, please vote for it. 

I cannot properly fix the error without a pretty big design and testing effort.  It is not as simple as changing the _RelativeOffsetOfHeader to be int64.  So for now, I would like to catch the errors that you described, and throw an appropriate, meaningful exception.  You can help me by describing what you did to get the IOExceptions.  what I would like from you is a recipe for how to reproduce the error you saw - ideally source code that reproduces the problem. 

Also, what version of the library are you using?

Nov 17, 2008 at 10:07 AM
Hey there,
I will compile a whole debug report and see what I can get out for you. But just FYI there are 14473 files with a total size of 4.5 gigs. I will see which of the files is the one that causes the problem and send it to you. But because of the size of the whole, yeah project I cannot provide all of them :)

And I am using the latest stable release of v1.6
Nov 17, 2008 at 5:25 PM
ha, ok.
Any archive over 4g in size will exhibit this problem.
any archive with an uncompressed file over 4g in size will exhibit this problem.

I should include some verification to detect overflow.

Dec 19, 2008 at 2:28 PM
Mozzy, can you get me some samples of zip64 archives?