How to diagnose File.delete() returning false / find unclosed streams?

I'm working with a 3rd party JPEG/EXIF manipulation library (Mediautil) that is causing me some headaches. I want to change an image's EXIF data. To do this, I need to write the updated version to a temporary file, delete the original and then rename the temp file to the original name.

My problem is that the File.delete() call fails and returns false, presumably because the library still has it opened in some way - but I have done everything I can find in the API to make it close all streams. Even worse: the problem seems to be timing-dependant, and the Unit tests where it occurs sometimes fail and sometimes not - but the code is not multithreaded.

Bizarrely, there is one library call that removes the problem - but it also removes the EXIF thumbnail, which I don't actually want. And looking at the code, I absolutely can't see where it closes 开发者_Go百科any streams that might otherwise stay open.

Any ideas how to attack this problem?

Edit: This is on Windows XP, Java 6. And another thing: I have found out that if I call System.gc() before calling File.delete(), it works - presumably because that triggers some finalizer. So it definitely seems to be an unclosed stream.

I would go for some help with the debugger here. A quick dig through the java.io stuff shows that the only likely finalize() candidate is in FileOutputStream. So slap a breakpoint in there, run your program, and try and get System.gc() to trigger FileOutputStream.finalize() to release your stream. That should give you an answer as to whether or not that's your problem.

Once you can reproduce that, then you need to start matching instantiation of FileOutputStream instances with their finalization. A good debugger will give you internal JVM object identifiers for each object, so if you can track the OIDs as they get created, and track them as they get finalized, then hopefully you'll be able to associate the key call to finalize with a specific call new new FileOutputStream.

Might be a long slog, though, depending how complex your application is.

If you are using a FileOutputStream, closing it explicitly allows for deletion of the file.

e.g. instead of:

File myFile = new File("test.txt");
myCustomStreamProcess(new FileOutputStream(myFile));
boolean test = myFile.delete(); //May return false

you should do:

File myFile = new File("test.txt");
FileOutputStream fos = new FileOutputStream(myFile);
myCustomStreamProcess(fos);
fos.close(); //Allow the document to be deleted afterwards
boolean test = myFile.delete(); //Should always return true

Why don't you rename the file before you get the library to open it? Then maybe use Java's File.deleteOnExit() to delete the renamed file. For example:

 File jpeg = new File("image.jpg");
 File temp = new File(jpeg + ".temp.jpg");
 jpg.renameTo(temp);
 SomeObj result = exifLibrary(temp); // or exifLibrary(new FileInputStream(temp);
 OutputStream jpegStream = new FileOutputStream(jpeg);
 output.write(result.bytes();
 output.close();
 temp.deleteOnExit();
 temp.delete();

And looking at the code, I absolutely can't see where it closes any streams that might otherwise stay open.

I think you could have identified the real problem; i.e. that the API you are using leaks open file handles by design.

Since this is an open source library you are using you have source code access. Therefore, you should be able to confirm this, and if necessary fix it for yourself. And to be a good citizen, contribute your fix back to the project by submitting a patch.