Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added Seeking feature for BufferedSubStream and ReadOnlySubStream. #583

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

vovgou
Copy link

@vovgou vovgou commented Mar 30, 2021

Added the seeking feature for BufferedSubStream and ReadOnlySubStream. When the compression type of an entry is Store (uncompressed) in the Zip or APK file, a seekable stream will be obtained by entry.OpenEntryStream(). In game development on the Android platform, it avoids having to decompress files to disk due to a seekable stream being required.

@vovgou
Copy link
Author

vovgou commented Mar 30, 2021

Hi,@adamhathcock
My submission failed to pass the test case, but this does not seem to be my problem. I tested some cases in which errors were reported on my computer, and it worked.

@adamhathcock
Copy link
Owner

Not sure how these pass locally for you as some of the code looks at the CanSeek flags to do different things. That's why the test is failing because ReadOnlySubStream was never seekable and now RewindableStream blows up because it's trying to seek.

I believe entry.OpenEntryStream() should always return a non-seekable stream as it's directly linked to decompression and inheritly shouldn't be seekable. If you want to buffer it for your app, do so, but I don't think this is something that should be part of SharpCompress.

@vovgou
Copy link
Author

vovgou commented Mar 31, 2021

Not sure how these pass locally for you as some of the code looks at the CanSeek flags to do different things. That's why the test is failing because ReadOnlySubStream was never seekable and now RewindableStream blows up because it's trying to seek.

I believe entry.OpenEntryStream() should always return a non-seekable stream as it's directly linked to decompression and inheritly shouldn't be seekable. If you want to buffer it for your app, do so, but I don't think this is something that should be part of SharpCompress.

Usually, entry.OpenEntryStream() gets a compressed stream that cannot be seeked, but in the zip file, if the Entry is a "Store" type, it is not compressed. In the game developed with Unity3d (Android APK), The files in the StreamingAssets directory are game resource files. They are all "Store" types and are not compressed. It is necessary to support a seekable stream. And when using SharpZipLib, it works.So could you support this feature? Thanks you.

@adamhathcock
Copy link
Owner

I guess if there's no decompression stream, then it could be a seekable stream when using OpenEntryStream. Just need to complete the thread and check for uncompressed streams in zips

@vovgou
Copy link
Author

vovgou commented Apr 1, 2021

I guess if there's no decompression stream, then it could be a seekable stream when using OpenEntryStream. Just need to complete the thread and check for uncompressed streams in zips

Yes, it is seekable, but it is wrapped by ReadOnlySubStream in sharpcompress, so i added the seeking feature to ReadOnlySubStream

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants