Strange problem with File.delete

Posted Tue, 14/09/2010 - 11:23 by tigor
, , ,

I have a strangest problem.  (running on Windows)

I have a class, which receives java.io.File as a parameter and stores reference in class attribute. The file is meant to be an XML file and class processes the file with XML parser.

At the end of the process i have a code that deletes the file. If all works well, the file is deleted.

However, if exception occurs, delete fails, returning false. I checked and rechecked - all access to file InputStream has finally statement, which suppose to close the streams. Yet, the file remains.

I debugged the code and when the program is about to delete the file - indeed even deletetion from file explorer fails with message from OS that file is locked.

 

Any suggestions?

 

Thanks

‹ Example of java cache and types of reference to object in Java Loading applet with custom class loader ›

Comments

by alex - 14/09/2010 - 13:20 
/* Force streams to be closed... */
System.gc();
/* Now you can delete a file*/
file.delete();

by shlomo - 14/09/2010 - 15:25

Even if System.gc() resolves the issue (which it might), I am strongly against explicit invocation of System.gc(). The first reason is that the JVM does not guarantee that it will actually garbage collect flowing that invocation, and the second reason is that GC might take any time from MS to several long seconds, why should you want to interfere with the JVM's internal GC mechanism?

See:

http://forums.sun.com/thread.jspa?threadID=538035

http://stackoverflow.com/questions/991489/i-cant-delete-a-file-in-java

 

 

 

 

by alex - 14/09/2010 - 16:00

It's known weird JVM behavior on Windows where things can keep a handle on a file longer than they should, IMHO it's a bug.
I agree that GC is ugly but some objects in the standard library seem to clean up file handles in their finalizers.

by tigor - 15/09/2010 - 12:34

System.gc() This was the first thing i've done. That didn't help :(

 

by shlomo - 15/09/2010 - 13:01

Does it work on Linux?

by tigor - 15/09/2010 - 17:48

Well, Linux works fine. I also read that this problem related to Windows only.

Basically, if it works on Linux that solves my bug.

But i am still puzzled about Windows...

by shlomo - 16/09/2010 - 11:29

Is the file located in a tmp folder? if so, try in another folder and see if the problem persists.

by tigor - 16/09/2010 - 12:09

No, i use my folder structure, which is built by the program

by evgenyg - 14/09/2010 - 15:16

 If you Ctrl+F this file in ProcessExplorer - who's holding the lock?

by tigor - 16/09/2010 - 12:12

The process explorer does not help, since it directs me to Java process, which naturally holds the lock. The problem is to know - which part of Java process does that. I checked with Profiler and i have a number of FileInputStreams, but i can't access the stack call for those object from Profiler, can I ?

by evgenyg - 16/09/2010 - 14:38

What Profiler are you using?

 

I would debug all third-party libraries having an access to this file to see how they "treat" it. It looks like one of them is holding a reference to FileInputStream and isn't closing it properly. If you find such a library you can upgrade it (may be it's an issue that was fixed already) or open them a bug or fix it and send them a patch.

 

And, hey, you're not the first person in the world leaving files undeleted - I cleanup my "temp" folder on Windows periodically, there's always tons of garbage there. I would store the file in a "temp" folder, attempt to delete it, fail, log the message and move on.

by oded - 21/09/2010 - 13:12

its know issue in Windows but still That's a little bit wierd because i have sort of the same Class in my project,

and that never happened there, so i wonder maybe you dont use Finally and closing streams?

or that you have a thread that is holding it?