Opening a tar.gz file directly from the network makes SharpZipLib to an attempt to access an already disposed Stream

[koide]

I'm downloading a file from an FTP server and unzipping, untarring it on the fly, via the underlying streams. The code looks like this:

var request = WebRequest.Create("ftp://host/file.tgz");
request.Method = WebRequestMethods.Ftp.DownloadFile;
request.Credentials = new NetworkCredential("user","password");
var response = (FtpWebResponse) await request.GetResponseAsync();
using (var gzStr = new GZipInputStream(response.GetResponseStream()))
{
    gzStr.IsStreamOwner = false;
    var tar = TarArchive.CreateInputTarArchive(gzStr);
    Directory.CreateDirectory(_targetPath);
    tar.IsStreamOwner = false;
    tar.ExtractContents(_targetPath);
}

With the current 1.2.0 release (and 1.1.0 and 1.0.0) I get an ObjectDisposedException on the network socket stream, but it happens after the whole file has been extracted successfully, so it seems to be yet another exceptional case happening after finishing the file.

In my total ignorance of this code, I've tracked the issue to this line:

SharpZipLib/src/ICSharpCode.SharpZipLib/GZip/GzipInputStream.cs

Line 122 in ab7f8c5

catch (Exception ex) when (completedLastBlock && (ex is GZipException || ex is EndOfStreamException))

 catch (Exception ex) when (completedLastBlock && 
    (ex is GZipException || ex is EndOfStreamException)) 

and, changing it to

catch (Exception ex) when (completedLastBlock && 
    (ex is GZipException || ex is EndOfStreamException ||
     ex is ObjectDisposedException))

makes my specific case work successfully. I think that the server ends the connection after the file is downloaded so the stream is not there to be read from anymore.

[Numpsy]

The discussion @ https://stackoverflow.com/questions/48829032/streamreader-readline-throwing-disposed-exception-rather-than-returning-null suggests that the FTP response stream closes itself when all the data is read, which could cause issues with stacked streams?

Maybe the multiple-block handling loop in GZipInputStream.Read could check stream.CanRead before trying to read a second block?

[koide]

Yup, looks like it's not the server but FtpWebRequest's FtpDataStream.

I can confirm that doing

while (toRead > 0 && inputStream.CanRead)

instead of

SharpZipLib/src/ICSharpCode.SharpZipLib/Zip/Compression/Streams/InflaterInputStream.cs

Line 119 in ab7f8c5

while (toRead > 0)

makes it work in my case as well, and looks like a saner approach.