File.delete takes time

[aaronfude]

In windows (not sure about unix) I find that if I iterate through files
in a dir and file.delete() each one and at the end of the loop I
immediately list the files in the directory, some of the files are
still there.

Does it take time after the delete for the files to actually go away?

Thanks!

Aaron Fude

 

[Frank Langelage]

In windows (not sure about unix) I find that if I iterate through files
in a dir and file.delete() each one and at the end of the loop I
immediately list the files in the directory, some of the files are
still there.

Does it take time after the delete for the files to actually go away?

Thanks!

Aaron Fude

Had a similar problem some time ago.
Calling the garbage collection with System.gc() after the loop before
checking should solve this issue.

 

[Daniel Dyer]

In windows (not sure about unix) I find that if I iterate through files
in a dir and file.delete() each one and at the end of the loop I
immediately list the files in the directory, some of the files are
still there.

Does it take time after the delete for the files to actually go away?

Did you check the return value of the delete method? It returns a boolean
indicating whether the delete was successful or not.

Dan.

 

[Daniel Dyer]

Had a similar problem some time ago.
Calling the garbage collection with System.gc() after the loop before
checking should solve this issue.

Calling System.gc() is rarely a solution for anything. It's not even
guaranteed to do anything. I'd guess that it just makes it look like
things are working. The real problem is likely to still be lurking
somewhere.

Dan.

 

[Mark Jeffcoat]

Calling System.gc() is rarely a solution for anything. It's not even
guaranteed to do anything. I'd guess that it just makes it look like
things are working. The real problem is likely to still be lurking
somewhere.

I'll second that.

If System.gc() does occasionally appear to help here, it likely
means that you're leaking open file handles somewhere. It may
seem convenient to let the garbage collector do your close()ing
for you, but it'll introduce serious problems if you try to, say,
delete or rename the file that still has an open FileInputStream
on it.

The exact kind of problem varies by platform, making this one
especially fun.

 

[Robert Mabee]

Calling the garbage collection with System.gc() after the loop before
checking should solve this issue.

If a Java object does something (like closing a file) when it is
finalized then that action is unpredictably delayed and can cause
surprising problems. One I ran into was a DB application that worked
fine under light test and soon stopped under load -- it turned out
that a SQL query held onto an item of a limited pool in the DB server
until garbage collection called the finalizer. The fix was to
explicitly close or finalize the query object before leaving the
function that used it.

Explicitly calling the garbage collector is a good way to detect this
class of problem and a bad way to fix it, both because it's expensive
and because it isn't guaranteed to do anything -- it's a "suggestion"
to the JVM.

However, I don't see a finalizer or close() in java.io.File. It would
be a significant bug if File's implementation held a system resource
like a file handle. Perhaps you are seeing an OS feature?

 

[Mark Jeffcoat]

If a Java object does something (like closing a file) when it is
finalized then that action is unpredictably delayed and can cause
surprising problems. One I ran into was a DB application that worked
fine under light test and soon stopped under load -- it turned out
that a SQL query held onto an item of a limited pool in the DB server
until garbage collection called the finalizer. The fix was to
explicitly close or finalize the query object before leaving the
function that used it.

Explicitly calling the garbage collector is a good way to detect this
class of problem and a bad way to fix it, both because it's expensive
and because it isn't guaranteed to do anything -- it's a "suggestion"
to the JVM.

However, I don't see a finalizer or close() in java.io.File. It would
be a significant bug if File's implementation held a system resource
like a file handle. Perhaps you are seeing an OS feature?

Sorry for the confusion; I was talking about problems with
unclosed FileInputStreams (and similar classes).


One idea I stole from Bruce Eckel's _Thinking in Java_ is a
way to use the finalizer to detect these problems. You can't
reliably use it to close an open stream, or return a resource
to a pool, but you can do something like

protected void finalize() throws Throwable {
assert(!resource.open());
}

in hopes of finding a place where you've broken the rules.
(I say hope because, of course, there's no guarantee that
the garbage collector will ever even run. This is a check,
not an excuse to stop paying attention.)