Object not closing

  • Thread starter Thread starter tshad
  • Start date Start date
T

tshad

I have a zipfile that I am trying to close because the file is corrupted and
I get an error on it:

Exception of type 'java.util.zip.ZipException' was thrown

So I handle the error and finally try to close the error. But there appears
to be some time of timing issue.

ZipFile zipfile = null;

try
{
zipfile = new ZipFile(zipFileName);
}
catch(Exception exc)
{
throw new Exception("File: " + zipFileName + " Corrupted",
exc);
}
finally
{
if (zipfile != null)
{
zipfile.close();
}
}

In the above code, I get the exception and get the if (zipfile != null) test
and this is where it all takes a different path depending on how long I
take.

If the "if" test was not there, I would get an error saying that the object
does not exist and I will then get an error saying that I can't move it
because it is in use. If I trace through it, it also doesn't get to the
zipfile.close(), but it allows me to move it so it is obviously not in use.

How can I handle this? I can't use a "using" clause as it is not
IDisposable.

It seems to close if I step through which seems to allow it to get released.

Thanks,

Tom
 
I found the problem (and the solution). The problem was that the
constructor is opening the .zip file passed and if it determines that the
file has a problem, it does an IOException but never closes the stream.

You have to wait until the Garbage Collector realizes that this object (the
..zip file) now has nothing pointing at it and closes it. But the problem is
you would never know when it was done.

So you do a System.GC.Collect() to force the Garbage Collector to do its
thing now. Now, there is no access problem.

It was really a couple line change:

ZipFile zipfile = null;

try
{
zipfile = new ZipFile(zipFileName);
}
catch(Exception exc)
{
throw new Exception("File: " + zipFileName + " Corrupted",
exc);
}
finally
{
if (zipfile != null)
{
zipfile.close();
}
else
System.GC.Collect();
}

Works perfectly.

Tom
 
Peter Duniho said:
I found the problem (and the solution). The problem was that the
constructor is opening the .zip file passed and if it determines that the
file has a problem, it does an IOException but never closes the stream.

You have to wait until the Garbage Collector realizes that this object
(the
.zip file) now has nothing pointing at it and closes it. But the
problem is
you would never know when it was done.

So you do a System.GC.Collect() to force the Garbage Collector to do its
thing now. Now, there is no access problem.

It was really a couple line change:

[...]

Works perfectly.
Click to expand...

Well, except for the fact that you're calling a method that you should
never need to call.

From your post, it looks like you're trying to use some Java library thing
from C#. My advice would be to ditch the buggy library. If they got that
wrong, who knows what other bugs you're going to run into.
Click to expand...

It is a Java library that is part of MS libraries. You have to reference
it, but it works well except for this problem. It was the only library I
could find that dealt with zip files and is pretty simple to use.

Thanks,

Tom
 
It is a Java library that is part of MS libraries.  You have to reference
it, but it works well except for this problem.  It was the only libraryI
could find that dealt withzipfiles and is pretty simple to use.
Click to expand...

Tom, have you checked out DotNetZip? It's free, much simpler to use,
(yes, it implements IDisposable), and doesn't require you to call
GC.Collect().
http://www.codeplex.com/DotNetZip .
 
It is a Java library that is part of MS libraries. You have to reference
it, but it works well except for this problem. It was the only library I
could find that dealt withzipfiles and is pretty simple to use.


Tom, have you checked out DotNetZip? It's free, much simpler to use,
(yes, it implements IDisposable), and doesn't require you to call
GC.Collect().
http://www.codeplex.com/DotNetZip .
Click to expand...

I probably will look at this for my next project.

I already have this one working and this has been my only problem with it.
When I was looking before for how to handle zip files I don't think I saw
this one or probably would have used it. This was part of the .net
libraries (even though it was in Java) and did the job when I needed it.

I agree, I would rather not have to call GC.Collect(). But it isn't the
worse thing that could happen, I suppose.

Thanks,

Tom
 
Back
Top