Exception thrown when updating a large (5GB) zip file

[zpst]

Steps to reproduce

1. Create a zip file (with SharpZipLib) with approx. 5 GB
2. Open the zip file (5 GB) as a FileStream
3. Open the file to be added (572 MB) as a FileStream
4. Call the methode UpdateZipInMemory https://github.com/icsharpcode/SharpZipLib/wiki/Updating

My modified method

      public void CallingExample()
      {
         FileStream fs = File.Open(@"c:\temp\existing.zip", FileMode.Open, FileAccess.ReadWrite);
         FileStream fsEntry = File.OpenRead(@"c:\temp\test1.zip");

         // Do the update
         UpdateZipInMemory(fs, fsEntry, "test1.zip");
         fsEntry.Close();

         fs.Close();
      }

Expected behavior

File is added to the zip archive.

Actual behavior

Exception is thrown
ICSharpCode.SharpZipLib.Zip.ZipException: "End of extra data"

ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipExtraData.ReadCheck(int length)
ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipExtraData.ReadLong()
ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipEntry.ProcessExtraData(bool localHeader)
ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipFile.ReadEntries()
ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipFile.RunUpdates()
ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipFile.CommitUpdate()

Version of SharpZipLib

• v1.0.0
• v1.0.0 RC2
• 0.86.0.518

Obtained from (place an x between the brackets for all that apply)

• Compiled from source
  • Source code (.zip) v1.0.0 and v1.0.0 RC2
• Downloaded DLL from GitHub (0.86.0.518)

[piksel]

This is unfortunately pretty hard to test. There's probably a counter that's overflowing somewhere, or perhaps a 32-bit limitation? Have you tried it in x64-mode?

[zpst]

Excuse me, I forgot this information. The error was in x64-mode.

[SeAlwin]

Same problem here. Opening a large (3GB) in our case, gives the same error, breaks at
using (var zipFile = new ZipFile(filePath)) with the exception mentioned by @zpst

I am using the latest released version (1.0)

[galakt]

@piksel What do you mean by "pretty hard to test" if it is pretty easy to reproduce (no offence). Got same problem

[Numpsy]

Might be worth testing this with the change from #310 in case it's the same problem and that fixes it.

(Think there may be a situation where it sets both the base compressed and uncompressed size fields to -1 and then only writes one of them to the extra data, and then blows up on read when half the data is missing. Possibly when the uncompressed size is above the non-zip64 size limit and the compressed size is below?).

[Numpsy]

Just running the test:

using (var tempStream = File.Open(@"BigZip64.zip", FileMode.Open, FileAccess.ReadWrite))
{
	using (ZipFile f = new ZipFile(tempStream, leaveOpen: true))
	{
		var m = new StringMemoryDataSource("0000000");
		f.BeginUpdate(new MemoryArchiveStorage());
		f.Add(m, "b.dat");
		f.CommitUpdate();
	}
}

with the attached file seems to repro it, and the fix for 310 does seem to help. (tried doing a test case that generates the file during the test, but it's probably too slow to be useful).

BigZip64.zip

[galakt]

Can confirm that #314 fixes my case