Zip corruption with ParallelDeflateThreshold != -1 #11
Description
If ParallelDeflateThreshold is set to other value than -1 (meaning to paralled compress files), I sometimes experience failing Zip64 tests. When aborting the test and inspecting the zipped files and compare them to the original files, 1, 2 or 3 characters are different in the compressed file.
This is not the case when setting ParallelDeflateThreshold to -1, so i think the parallel compression from time to time messes things up - but I have only seen it with Zip64Option.Never. Never came to test that with Zip64Option.AsNecessary