Object not closing

[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

[tshad]

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
"tshad" <tf*@dslextreme.comwrote in message
news:uy*************@TK2MSFTNGP06.phx.gbl...

>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

[Peter Duniho]

On Wed, 01 Oct 2008 18:00:00 -0700, tshad <tf*@dslextreme.comwrote:

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.

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.

Pete

[tshad]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Wed, 01 Oct 2008 18:00:00 -0700, tshad <tf*@dslextreme.comwrote:

>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.

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.

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

>
Pete

[Cheeso]

On Oct 2, 4:01*pm, "tshad" <[e-mail]:

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
fromC#. *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.

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.

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 .

[tshad]

"Cheeso" <dp******@mailinator.comwrote in message
news:49**********************************@k36g2000 pri.googlegroups.com...
On Oct 2, 4:01 pm, "tshad" <[e-mail]:

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
fromC#. 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.

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 .

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