Java keeps lock on files for no apparent reason

Question

Despite closing streams in finally clauses I seem to constantly run into cleaning up problems when using Java. File.delete() fails to delete files, Windows Explorer fails too. Running System.gc() helps sometimes but nothing short of terminating the VM helps consistently and that is not an option.

Does anyone have any other ideas I could try? I use Java 1.6 on Windows XP.

UPDATE: FLAC code sample removed, the code worked if I isolated it.

UPDATE: More info, this happens in Apache Tomcat, Commons FileUpload is used to upload the file and could be the culprit, also I use Runtime.exec() to execute LAME in a separate process to encode the file, but that seems unlikely to cause this since ProcessExplorer clearly indicates that java.exe has a RW lock on the file and LAME terminates fine.

UPDATE: I am working with the assumption that there is a missing close() or a close() that does not get called somewhere in my code or external library. I just can't find it!

Solution 1

The code you posted looks good - it should not cause the issues you are describing. I understand you posted just a piece of the code you have - can you try extracting just this part to a separate program, run it and see if the issue still happens? My guess is that there is some other place in the code that does new FileInputStream(path); and does not close the stream properly. You might be just seeing the results here when you try to delete the file.

Solution 2

I assume you're using jFlac. I downloaded jFlac 1.3 and tried your sample code on a flac freshly downloaded from the internet live music archive. For me, it worked. I even monitored it with ProcessExplorer and saw the file handles be opened and then released. Is your test code truly as simple as what you gave us, or is that a simplified version of your code? For me, once close() was called, the handle was released and the file was subsequently successfully deleted.

Try changing your infinite loop to:

File toDelete = new File(path);
if (!toDelete.delete()) {
  System.out.println("Could not delete " + path);
  System.out.println("Does it exist? " + toDelete.exists());
}

or if you want to keep looping, then put a 1 second sleep between attempts to delete the file. I tried this with JDK6 on WinXP Pro.

Don't forget to put a try/catch around your close() and log errors if the close throws an exception.

Comments

[Brett]

(In practice FileInputSteram.close will not actually throw, although that is no excuse.)

[Eddie]

The while loop isn't empty, exactly. It says, while the file isn't successfully being deleted, try again to delete it.

[TofuBeer]

it would make a difference if he is somehow keeping a hold of some of the other objects which in turn is causing the streams to be saved. THough once the stream is closed I cannot see why it would keep the file locked. I suspect he has some sort of resource leak.

[Jonas K]

Thanks Eddie, I will also make a simpler testcase and get back.

[Jonas K]

I have now used ProcessExplorer and it clearly indicates java.exe to have a handle with Share flag RW.

[Jonas K]

I have now used ProcessExplorer and it clearly indicates java.exe to have a handle with Share flag RW. Does that mean I should be looking for unclosed FileOutputStreams?

[Jonas K]

You are right, that code was not the cause, the lock is created elsewhere in my app. Searching...

[Bogdan]

It is hard to guess what it is that you are doing with those files :-) But my guess is it should not be too hard to go through the code and find all the places where you potentially read/write that file and make sure the streams are closed.

[nog642]

Since ProcessExplorer shows the file is opened for writing I would say it's not closed properly by commons-fileupload. Perhaps you can post the code that uses commons-fileupload?

[Jonas K]

Yes, but I just can't find that missing finally block? FileUpload seems to do things right...

[John Gardner]

Yes, your while isn't "empty", but your while is "dumb". its checking the exact same state over and over, and the inside of the while loop doesn't do anything to change it. how many times do you want the OS to tell you "you can't delete that file" without putting in some code to figure out why?