mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-08 13:34:57 +00:00
Some zip files have incorrect file size calculations #364
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zhusheping on GitHub (Aug 12, 2019).
which lead to the file size soaring after decompression.
I don't want test files published in public space. I can't find your email. If you email me, I will attach it to the reply.
@adamhathcock commented on GitHub (Aug 12, 2019):
Is this a flaw in other implementations too or specific to SharpCompress?
@zhusheping commented on GitHub (Aug 13, 2019):
I's specific to SharpCompress.
And now,in my project,i use System.IO.Compression for zip file and sharpcompress for rar.
I've also tried DotNetZip,SevenZip,and they are all ok.but dotnetzip just support zip,and i don't like using sevenzip's method of referencing DLL libraries.
I guess it's a bug for sharpcompress.
Attached is a private document, please do not disseminate it.Thanks a lot.
Is this a flaw in other implementations too or specific to SharpCompress?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
从QQ邮箱发来的超大附件
23261-01b-1555762529053.zip (133.70M, 2019年09月12日 08:49 到期)进入下载页面：http://mail.qq.com/cgi-bin/ftnExs_download?t=exs_ftn_download&k=36376363a6f19d96a4266f6345350b4e5f03520107040b034b05075b50180d0456004e5b53515a4c5556545302540d545e0f5006632e3953550555524e0508034b06565656020f5353055a535606171b0f47635e&code=f7ccc59a
@adamhathcock commented on GitHub (Aug 20, 2019):
If you could debug this with your file and submit a pull request, that would be great
@zhusheping commented on GitHub (Aug 21, 2019):
The entry size is correct until which line of debugging is executed.
I don't know why it keep files with another size.
Additional, when "var entryStream = archiveEntry.OpenEntryStream();" executed, archiveEntry.Size and archiveEntry.CompressedSize All become zero.
If you could debug this with your file and submit a pull request, that would be great
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
@adamhathcock commented on GitHub (Aug 21, 2019):
can you attach a code snippet and maybe some comments where it's going wrong?
@zhusheping commented on GitHub (Aug 22, 2019):
I guess the problem is in line 25 of the SharpCompress. Archives. IArchiveEntry Extensions. CS file. When 24 lines are executed, archiveEntry. Size and archiveEntry. CompressedSize are correct. When 25 lines are executed, archiveEntry. Size and archiveEntry. CompressedSize become zero.
24: streamListener.FireFilePartExtractionBegin(archiveEntry.Key, archiveEntry.Size, archiveEntry.CompressedSize);
25: var entryStream = archiveEntry.OpenEntryStream();
Since the data is miscalculated, the part written to the file after 25 line is naturally wrong.
@adamhathcock commented on GitHub (Aug 30, 2019):
Looks like the entry values should be cached somehow instead of dynamically calculated. Opening the entry stream is probably the cause since the data stream advances.