SharpDevelop Community

I have a set of 8 files totalling 660 Mb.

When I unzip them with SharpZipLib 0.85.4, I get the following error:

Error with file IndiaBio.zip : System.ObjectDisposedException: Cannot access a closed file.
   at System.IO.__Error.FileNotOpen()
   at System.IO.FileStream.Seek(Int64 offset, SeekOrigin origin)
   at ICSharpCode.SharpZipLib.Zip.PartialInputStream.Read(Byte[ buffer, Int32 offset, Int32 count)
   at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.Fill()
   at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream.Fill()
   at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream.Read(Byte[ buffer, Int32 offset, Int32 count)
 

I always get this error, but it happens on different files every time, some times, I get no error, and some times, I get an error on almost all files.

This error appears more frequently when I run the unzip on a set of 2 Gb of files.

Strangely, version 0.84 doesn't have a problem.

Any idea ?

Hi,

How are you creating the ZipFile instance you are using?  The only places the stream is closed is when its being updated or when its closed.  The partial input stream never closes anything.

Cheers, -jr-

Sorry for the slow reply.

Here is the VB.NET code I'm using:

    Public Shared Sub Unzip(ByVal inputStream As Stream, ByVal destinationFolder As String)
        inputStream.Position = 0
        Dim zFile As New ZipFile(inputStream)
        For Each e As ZipEntry In zFile
            If e.IsDirectory Then
                Directory.CreateDirectory(Path.Combine(destinationFolder, e.Name))
            End If
            If e.IsFile Then
                Dim readStream As Stream = zFile.GetInputStream(e)

                Dim destinationFilePath As String = Path.Combine(destinationFolder, e.Name)
                Dim readCount As Integer
                Const BufferSize As Integer = 2048
                Dim readBuffer(BufferSize - 1) As Byte

                Dim destinationPath As String = Path.GetDirectoryName(Path.GetFullPath(destinationFilePath))
                If Not Directory.Exists(destinationPath) Then
                    Directory.CreateDirectory(destinationPath)
                End If

                Dim writeStream As New FileStream(destinationFilePath, FileMode.Create)
                Dim size As Integer = 0
                While (True)
                    readCount = readStream.Read(readBuffer, 0, BufferSize)
                    If readCount <= 0 Then
                        Exit While
                    End If
                    size += readCount
                    writeStream.Write(readBuffer, 0, readCount)
                End While
                writeStream.Close()

                File.SetLastWriteTime(destinationFilePath, e.DateTime)

                If e.Size <> size Then
                    Throw New Exception("Sizes do not match: " & size & " (actual) and " & e.Size & " (in zipfile)")
                End If
            End If
        Next
    End Sub

 

SharpZipLib crashes on the line:

                   readCount = readStream.Read(readBuffer, 0, BufferSize)

With the error:

Error with file IndiaBio.zip : System.ObjectDisposedException: Cannot access a closed file. at System.IO.__Error.FileNotOpen() at System.IO.FileStream.Seek(Int64 offset, SeekOrigin origin) at ICSharpCode.SharpZipLib.Zip.PartialInputStream.Read(Byte[ buffer, Int32 offset, Int32 count) at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.Fill() at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream.Fill() at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream.Read(Byte[ buffer, Int32 offset, Int32 count) at MonitoringLibrary.ZipManager.Unzip(Stream inputStream, String destinationFolder) at MonitoringLibrary.ProviderActions.CheckFile(String filePath) at MonitoringLibrary.ProviderActions.ParseFolder()

Hi,

I still dont have a lead on this.  What environment is this code running in?  I am wondering if run its as a command line program to do just this code that it might work?

Cheers,

-jr-

Environment: Windows 2003 Server, running in a virtual machine. It has 1Gb of RAM (I'm not sure).

It runs as a command line program, and is launched by the Windows scheduler.

As I said, the best approach is to try with a large set of ZIP files.

I have the problem with more than 1600 Mb of zips, and especially on large files.

I'm getting this error too, only difference that I'm getting it always in Release build and never in Debug.

Version : 0.85.4.369

OS: Win2003 x64 or Win2000 under VMWare

test.zip contains one large file with name 'test' (I've used files from 3Mb to 10Mb, on small files its working without exception).

Sample to reproduce this error:

string fileName = @"test";

ZipEntry zippedFile = arc.GetEntry(fileName);

Having the "same" problem.

Version 0.85.4, built on 9/9/2007

OS: Windows XP
.Net 2.0 Sp1
Language: C#

Error only occurs in Release mode. This is a windows forms project written in C#.

Compressed file is 217,490kb and was created with the same version of SharpZipLib. During extraction, an ObjectDisposedException will occur randomly at line 3568 of ZipFile.cs (PartialInputStream).

ICSharpCode.SharpZipLib.Zip.ZipFile zip=new ICSharpCode.SharpZipLib.Zip.ZipFile(CompressedStream);
Stream file=zip.GetInputStream(0);
byte[ buffer=new byte[4096];
int i;
  while((i=file.Read(buffer, 0, 4096))>0) {
  [...]

System.ObjectDisposedException occurred
  Message="Cannot access a closed file."
  Source="mscorlib"
  ObjectName=""
  StackTrace:
       at System.IO.__Error.FileNotOpen()
  InnerException: 

Stack Trace:
     mscorlib.dll!System.IO.__Error.FileNotOpen() + 0x39 bytes    
     mscorlib.dll!System.IO.FileStream.Seek(long offset = 3260467, System.IO.SeekOrigin origin = Begin) + 0x33 bytes    
>    Program.exe!ICSharpCode.SharpZipLib.Zip.ZipFile.PartialInputStream.Read(byte[ buffer = {byte[4096]}, int offset = 0, int count = 4096) Line 3568    C#
     Program.exe!ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.Fill() Line 159    C#
     Program.exe!ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream.Read(byte[ buffer = {byte[4096]}, int offset = 2466, int count = 4096) Line 681 + 0xb bytes    C#

It hasn't occured with much smaller files, but I'm not going to claim it will *never* do so.

Will gladly provide more info, but I will need to be directed a bit..

Regards,
dboune

 Hi,

If you can debug this the quick way to figure this out is to set a breakpoint in the ZipFile.DisposeInternal that actually closes the stream and see where this happens and hopefully why.

I dont see how this is happening currently. 

I also set breakpoints anywhere "Dispose" or "DisposeInternal" is called. Never did it break at any of those points.

I don't see how this is happening either. In this case it appears the Finalize method is being called, which if my understanding is correct, specifically means GC. Nobody is calling Dispose implicitly, and the object has live references, which completely blows what understanding of GC and destructors I have right out of the water.

>    Program.exe!ICSharpCode.SharpZipLib.Zip.ZipFile.DisposeInternal(bool disposing) Line 2855    C#
     Program.exe!ICSharpCode.SharpZipLib.Zip.ZipFile.Dispose(bool disposing) Line 2869    C#
     Program.exe!ICSharpCode.SharpZipLib.Zip.ZipFile.Finalize() Line 519 + 0x7 bytes    C#

 Continuing to step through, once the finalize member is exited, we are immediately back at line 3568 from my previous post.

ZipFile arc = new ZipFile(fs);

ZipEntry zippedFile = arc.GetEntry(fileName);

string records = new StreamReader(arc.GetInputStream(zippedFile), Encoding.GetEncoding(866)).ReadToEnd();

After the call the GetInputStream, the ZipFile is not used anymore and can be finalized. As a workaround, add GC.KeepAlive(arc); after the "string records=" line.

SharpZipLib must be changed so that the zip file is not closed when there are no references to the ZipFile but still references to ZipInputStreams reading from that file.

Yep.. that did it for me. Alternatively, placing a ZipEntry.Close() at an appropriate location after the while loop in my above code had the same essential effect.

Thanks for that explanation Daniel. My understanding is enhanced, and I think I should be able to diagnose similar troubles much more effectively in the future.

Thank you too John, for being so willing and quick to answer this thread. That is greatly appriciated.

Best Regards,
dboune 

 BTW: Does this need a bug report? Chalk it up to expected behavior?

DanielGrunwald:

After the call the GetInputStream, the ZipFile is not used anymore and can be finalized.

Thanks for this explanation. So it's closing MY stream without permission :). I think, additional boolean parameter required for ZipFile constructor to tell ZipFile class that he owns this stream object or he is not.

I will change the library to cater for this.

Cheers, -jr- 

This has been fixed.  There are a few fixes lurking now so I might do a 0.85.5 release some time soonish.

 Thank you John! Looking forward to it.

Regards,
dboune