Use CompressionMethod.Stored and flush the ZipOutputStream after each entity was added leads Zip corrupted in SharpZipLib 1.4.2
Describe the bug
I found a bug that if I set CompressionMethod = CompressionMethod.Stored in the entry and flush the ZipOutputStream, the output zip is corrupted and only the first file exists in the zip file.
using (Stream NewZipStream = File.OpenWrite(Path.GetRandomFileName()))
using (ZipOutputStream ZipStream = new ZipOutputStream(NewZipStream , StringCodec.FromEncoding(Encoding.UTF8)))
{
ZipStream.SetLevel(0);
ZipStream.UseZip64 = UseZip64.Dynamic;
ZipStream.IsStreamOwner = false;
foreach (string FilePath in Directory.EnumerateFiles("<Your folder that has multiple files>"))
{
using (Stream FileStream = File.OpenRead(FilePath))
{
ZipEntry NewEntry = new ZipEntry(File.Name)
{
DateTime = DateTime.Now,
CompressionMethod = CompressionMethod.Stored,
Size = FileStream.Length
};
await ZipStream.PutNextEntryAsync(NewEntry, CancelToken);
await FileStream.CopyToAsync(ZipStream);
await ZipStream.CloseEntryAsync(CancelToken);
}
await ZipStream.FlushAsync(CancelToken);
}
}
Reproduction Code
No response
Steps to reproduce
- Use ZipOutputStream
- Set CompressionMethod to CompressionMethod.Stored on ZipEntry
- Add multiple files/folders into ZipOutputStream
- Flush the ZipOutputStream once each entity was added
- Found the zip file is corrupted
Expected behavior
Zip is not corrupted
Operating System
Windows
Framework Version
.NET 7
Tags
ZIP
Additional context
No response
这是来自QQ邮箱的假期自动回复邮件。 您好,我最近正在休假中,无法亲自回复您的邮件。我将在假期结束后,尽快给您回复。
only the first file exists in the zip file.
You are adding the same file many times, using the same name. Most archivers would probably only display that as a single file entry.
Could you upload the output file to ArchiveDiag and post the URL to the resulting analysis here?
@piksel Yes that just a sample, just let you know that I added multiple files
Sorry, further test shows that this issue related to FlushAsync() on ZipOutputStream, here is the demo. Make sure there are some files in your "~\Picures\Screenshot" folder
In short, if CompressionMethod is not CompressionMethod.Stored or do not flush the ZipOutputStream after insert a new entry, this issue disappeared.
I tried to reproduce your issue but it works correctly: https://dotnetfiddle.net/IDUcxf
I have tested in two different PCs using the demo I provided before. And the result is the same, please try use the demo application instead:
Demo application SharpZipLibTest.zip will try zip your Screenshots folder in 4 different ways, output zip file will be placed on your desktop. Test1.zip is corrupted and Test2.zip & Test3.zip Test4.zip are correct. Please check code of the demo application
@piksel Could you reproduce this issue using the demo application?