mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-03 21:23:38 +00:00
Depend on SharpZipLib #372
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 @adamhathcock on GitHub (Sep 7, 2019).
Thinking of using https://github.com/icsharpcode/SharpZipLib Instead of directly using implementations of my own (or forked earlier). SharpZipLib used to be LGPL so I never looked at it. Now it’s MIT.
This project was never about implementing the algorithms or even the archive formats but having an easy and unified interface while allowing forward-only access.
Probably relates to #470
@adamhathcock commented on GitHub (Sep 7, 2019):
Probably cannot directly use nuget packages as not much is useful. Probably some code porting is required
@Svetomechc commented on GitHub (Nov 20, 2019):
Why not use https://docs.microsoft.com/ru-ru/dotnet/api/system.io.compression ?
@adamhathcock commented on GitHub (Nov 21, 2019):
Because I need access to a lot of the internals of archive formats and they don’t expose them. Otherwise, I’d love to.
@turbolocust commented on GitHub (Nov 23, 2019):
Offering interruptible async API's would then be more difficult, because you would loose control over portions of the code. SharpZipLib does not support them yet: https://github.com/icsharpcode/SharpZipLib/issues/223
@adamhathcock commented on GitHub (Nov 23, 2019):
I need to put some brain power to what the proper way is to implement async for streams. Often I see that there’s nothing really to do?
@turbolocust commented on GitHub (Dec 3, 2019):
A task has to be returned, that's basically all there is to do (see this link). If the operation should be cancelable, then a CancellationToken should be supported by the API. Streams in .NET usually support this. But if instantaneous cancellation is required, the algorithm that does the archiving logic should support this as well. Also, according to the link in my previous post, SharpZipLib does not support async methods in their stream classes, which is why I wouldn't consider using their library as long as this feature is missing.
@adamhathcock commented on GitHub (Dec 3, 2019):
I meant more like if I use the async methods is that good enough? Would sync reuse the async code paths okay?
Not sure at the moment.
@Svetomechc commented on GitHub (Dec 4, 2019):
@adamhathcock you mean sync methods actually calling async ones with .GetAwaiter().GetResult()?
@adamhathcock commented on GitHub (Dec 4, 2019):
Like if I only implement the async part of Streams, does it use that path if someone uses the sync part?
I don’t want to have people use GetAwaiter().Result() or Wait() which ties up an extra thread.
@Svetomechc commented on GitHub (Dec 4, 2019):
@adamhathcock that is a really good question.
@Bluscream commented on GitHub (Mar 10, 2024):
which noone was ever able to answer :D
@adamhathcock commented on GitHub (Mar 11, 2024):
nope
I'd probably just make everything async and let the Stream overloads (or provide them myself)
async has been around long enough
@Sergey-Terekhin commented on GitHub (May 23, 2024):
Just for your information: your implementation of Zip archive preserves non-ascii filenames like
português.jpgor测试.jpgorкириллица.jpgwhile the implementation from Microsoft (System.IO.Compression) may decode file names incorrectly. So, please, do not switch to alternate libraries :)@Bluscream commented on GitHub (May 23, 2024):
Or y'know; just fix System.IO.Compression and use that xD