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 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.iostuff shows that the only likelyfinalize()candidate is inFileOutputStream. So slap a breakpoint in there, run your program, and try and getSystem.gc()to triggerFileOutputStream.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
FileOutputStreaminstances 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 tofinalizewith a specific call newnew FileOutputStream.Might be a long slog, though, depending how complex your application is.