Add multistream support to BZip2 #417
Conversation
|
(fixes #413 rather than 276?) |
|
Gah. Github! Instead of using the number I actually typed, it auto-completed to the first search result that started with the number (413). |
|
Not sure if this would be considered a real issue or not, but in case: Does the usage of the Length property on the baseStream have any ramifications on the supported types of input stream? Example: Say that I have a Zip file that contains a BZip2 file. With the current code I appear to be able to open a BZip2InputStream on the stream that is returned from ZipFile.GetInputStream and read the data from it, but with this change I get I'm not sure off hand is BZip2InputStream is inteded to support such streams though? (might possibly also happen if you tried it with a network stream or some such as well) |
|
In which release this will be available? |
|
This will probably be in the next release. I have been super busy and neglected this unfortunately. Hopefully I will get time this weekend to fix current issues. |
| /// Construct instance for reading from stream | ||
| /// </summary> | ||
| /// <param name="stream">Data source</param> | ||
| public BZip2InputStream(Stream stream) : this(stream, true) { } |
There was a problem hiding this comment.
| public BZip2InputStream(Stream stream) : this(stream, true) { } | |
| public BZip2InputStream(Stream stream) : this(stream, stream.CanSeek) { } |
| long bytesProcessed = baseStream.Position - processedLastStream; | ||
| long bytesLeft = baseStream.Length - baseStream.Position; | ||
| if (multiStream && bytesProcessed > 0 && bytesLeft > 0) | ||
| { | ||
| processedLastStream = bytesProcessed; | ||
| Initialize(); | ||
| } | ||
| else | ||
| { | ||
| return -1; // ok | ||
| } |
There was a problem hiding this comment.
| long bytesProcessed = baseStream.Position - processedLastStream; | |
| long bytesLeft = baseStream.Length - baseStream.Position; | |
| if (multiStream && bytesProcessed > 0 && bytesLeft > 0) | |
| { | |
| processedLastStream = bytesProcessed; | |
| Initialize(); | |
| } | |
| else | |
| { | |
| return -1; // ok | |
| } | |
| if(!multiStream) { | |
| return -1; // no multistream support, so just end it here | |
| } | |
| long bytesProcessed = baseStream.Position - processedLastStream; | |
| long bytesLeft = baseStream.Length - baseStream.Position; | |
| if (bytesProcessed > 0 && bytesLeft > 0) | |
| { | |
| processedLastStream = bytesProcessed; | |
| Initialize(); | |
| } | |
| else | |
| { | |
| return -1; // ok | |
| } |
| /// <param name="outStream">The output stream to receive the decompressed data.</param> | ||
| /// <param name="isStreamOwner">Both streams are closed on completion if true.</param> | ||
| public static void Decompress(Stream inStream, Stream outStream, bool isStreamOwner) | ||
| => Decompress(inStream, outStream, isStreamOwner, true); |
There was a problem hiding this comment.
| => Decompress(inStream, outStream, isStreamOwner, true); | |
| => Decompress(inStream, outStream, isStreamOwner, inStream.CanSeek); |
There was a problem hiding this comment.
I'm not certain if there aren't any streams that support seeking but don't allow access to their length, but maybe that's too much of an unusual situation to worry about, and as long as the functionality can be disabled that should cover the situation if needed.
There was a problem hiding this comment.
I don't know if seeking can even be achieved if you don't allow Length (since the SeekOrigin parameter of Seek() call can be set to End.
The Stream documentation basically thinks of them as mutually inclusive:
https://docs.microsoft.com/en-us/dotnet/standard/io/?view=netframework-4.8#streams
There was a problem hiding this comment.
That's why I said too unusual to worry about (it might not make sense, but that doesn't guarantee it won't happen!).
Not a reason to avoid making the change though
|
@Numpsy I made suggestions that should make it compatible with non-seekable streams. It will not access Stream.Length if |
Fixes #413.
Fixes #162.
I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.