Created attachment 11436 [details]
Reproduction of bug
The constructor for System.IO.Compression.ZipArchive(Stream) does not work with the result of HttpClient.GetStreamAsync.Result (which returns System.Net.WebConnectionStream).
Instead, it throws System.IO.InvalidDataException with the message "The contents of the stream are not in the zip archive format."
This is System.IO.Compression bug which requires Seek capability for zip read mode whereas .net requires CanRead only.
Same bug here for System.Net.FtpDataStream (CanSeek=false, CanRead=true) on Linux. So I just got the mono source and compiled my app against the System.IO.Compression.dll and .mdb. The inner exception which was before "null" is now the following System.ArgumentException from the SharpCompress library:
"Archive streams must be Readable and Seekable"
The method in SharpCompress's AbstractArchive class:
private static Stream CheckStreams(Stream stream)
if (!stream.CanSeek || !stream.CanRead)
throw new ArgumentException("Archive streams must be Readable and Seekable");
The bug seems to sit in sharpcompress which is testing all input streams against this method. Funnily they write in their readme: "The major feature is support for non-seekable streams so large files can be processed on the fly (i.e. download stream)." (https://github.com/adamhathcock/sharpcompress)
I've tried to look into this bug last week.
If you remove those checks then the stream will fail when SharpCompress tries to seek to the end, to read the Zip header.
A simple fix would be to download the whole stream first into memory and pass it for further handling but that feels like an hack.
Another solution would be try to use their ReaderFactory API which I think is the one that supports streaming but I didn't look if it would be possible to implement the whole .NET API with it.
I am getting this exception when opening a stream that I have fully loaded into memory. So my unit test looks like this:
var zip = new ZipArchive(stream);
The first three assertions work fine. The Length is correct. The final line throws the "ArgumentException: Archive streams must be Readable and Seekable". This one has me baffled.
Do you have a reproduction case I could test with?
Ok I will try to put together a a simple app to isolate the issue and post it here. Thank you.
Sorry for the trouble. I was dealing with a zip within a zip and the inner zipped folder was not being wrapped in a seekable stream on Mono. Working now. It would be nice of course if the Mono (SharpCompress) implementation behaved as .NET does, not require a seekable stream. Thanks for your prompt response by the way.
Hello, I still have this problem and created a application for you to simply reproduce this issue: https://github.com/LinuxDoku/mono-bug-30686/blob/master/mono-bug-30686/Program.cs
This application works on my windows 10 machine with .NET Framework 4.5, but not with the latest mono version on ubuntu: "Stable 188.8.131.52/832de4b".
In the app above I faked the "CanSeek" property which is set to "false", equal to the behaviour when you are receiving the data from "FtpDataStream".
Looking into this.