Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
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 18.104.22.168/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.