was always taught to leave a place cleaner than when I got there, and I hold my applications to the same standard. However, a recent Java project I worked on was doing just the opposite, dumping temporary files on the user’s system and never cleaning them up. Fearing the inevitable tech support call after the application filled the user’s hard disk, I had to fix the problem.
The scenario was simple enough: like many applications, mine had to create temporary files on the user’s system during its execution and it then—in theory—would clean them up at exit. The requirement for temporary files (short-lived files normally created in a designated temporary directory) varies from project to project. Applications requiring large batch processing may use temporary files as an intermediate step, while other apps use them to buffer input and output (I/O) from a network or a device. In my case, the temporary files, commonly called temp files, were actually Java Archives (JARs) created at runtime and loaded dynamically into the application (which I later found exasperated the situation). As the project deadline approached, I had to find the problem and, more importantly, develop a solution.
Due to two open Java bugs, a Java application that utilizes a combination of the JVM design and the Win32 operating system does not allow temp files to be deleted if they are open at exit. As a result, the application dumps temporary files on the user’s system and never cleans them up.
The JVM can perform a quick cleanup step at startup to delete any temporary files that are lying around from the application’s previous run. However, because the temp files must be marked as locked when they are created, put all of the temp files for a given instance of the application into a single directory and lock the directory.
The Little Problems That Cause Big Headaches
The Java Foundation Classes (JFC) provide a mechanism for applications to create and destroy temporary files. Using the java.io.File class, an application can create a temporary file and mark it for deletion quite simply, as seen in the following code:
File tempFile = File.createTempFile("myApp", ".tmp");tempFile.deleteOnExit();The method deleteOnExit() is designed to allow an application to clean up files when the Java Virtual Machine (JVM) exits. In a perfect world, this would handle all cases. However, I didn’t see this behavior in my application. Although the file was being marked for deletion, it definitely wasn’t being deleted. To complicate matters, I soon discovered that the file was being deleted when the application was run on Linux. It was time to do some research.
After some detective work, I finally had an answer to the problem. Two open Java bugs were to blame. First was bug 4171239: “java.io.File.deleteOnExit does not work on open files (win32).” Unfortunately, a combination of the JVM design and the Win32 operating system does not allow the files to be deleted if they are open at exit. So all I would have to do is ensure I close all the files before exit, right? Wrong. This leads to bug 4950148: “ClassLoader should have an explicit disposal mechanism.” It turns out that an URLClassLoader, which is used to load classes from a JAR file, keeps the stream to the JAR open during the lifetime of the JVM. I was stuck. A Win32 JVM can’t delete an open file, and an URLClassLoader always keeps the file open. I had to think outside the box.
A simple solution would be to have my application always create temporary files with the same prefix, then delete all files with that prefix at some other time. The problem is that solution would not allow multiple instances of the application to run, since there would be a race condition between one instance creating temporaries and another deleting them. I also could unwittingly choose the same prefix as a different application, accidentally deleting its temp files. I needed something more robust and reusable, so I could make sure that all my projects cleaned up like they should.
Design: Building a Better File Trap
What I needed was a temporary file manager: a class that could create temporary files for me, and ensure that they were destroyed at some point in the future. Due to the bugs in the JVM, I was willing to accept that the temporary files may not get cleaned up until the next run of the application. Even with this relaxation in the requirements, I could still guarantee that the user would have only one set of temporary files on their system between runs.
In most cases, the best solution is the simplest one. Since the JVM could already delete files as long as the file was not open, I wanted to leverage this functionality as much as possible. I knew that when a JVM first starts up, it doesn’t have any temp files open. Therefore, it can perform a quick cleanup step to delete any files that may be lying around from the last run. However, when creating a temporary file, the file must be marked as locked, so no other application using the same temporary file management scheme will try to clean up active files. To reduce the number of lock files, I decided to put all of the temp files for a given instance of the application into a single directory and lock the directory.
Now that I had a solution designed, it was time to code it up.
Implementation: Plugging a Hole, Fixing a Leak
To keep things simple, I wanted an API similar to the File class already in the JFC. I created a class, TempFileManager, to handle the creation of temporary files as well as the cleanup of existing files. The first method, createTempFile(String prefix, String suffix), shown in Listing 1, behaves just like the File‘s method to any callers. The internals are a bit different, however. The manager first checks to see if it has been initialized. If it hasn’t, the manager generates a directory name relative to the system temporary directory and then creates a lock file for it. Finally the temp directory is created. Performing the steps in this order ensures that there is no race condition allowing another manager to delete the temp directory before the lock is created. The lock file is marked for deletion at exit, which will work since nothing in the JVM is holding an open reference to it. Finally, the method creates the temporary file that the user requested in the new directory.
The next important method in the TempFileManager isn’t really a method at all, but rather a static initialization block. The JVM runs this block when the class is loaded for the first time. This ensures that the manager will have a chance to clean up any old temp files as soon as the application requests the class, and it does not require the application to tell the manager to perform this cleanup.
Within the static {} block in Listing 1, the manager obtains a list of the files in the temporary directory, using a file filter to get only directories that begin with the magic temp file manager prefix. For each directory found, a check is performed to find the lock file. If no lock file is found, the directory is recursively deleted using the utility method recursiveDelete(File rootDir). With this implementation of the manager, a single instance would clean up temporary files from any number of other applications using the same manager implementation.
Using the TempFileManager in an application is quite simple. To ensure that the temp file manager cleans up leaked files from a previous run, force the JVM to load the class:
Class.forName(TempFileManager.class.getName());This step is not required since generating a new temporary file will cause the manager to be loaded, but explicitly loading the manager can be useful for documentation purposes. To create a new temporary file, the call is almost identical to the JFC API:
File myTmp = TempFileManager.createTempFile("foo", ".bar");Leak Plugged—Headache Avoided
With a solution designed and implemented, I was able to replace all calls to java.io.File#createTempFile(...) with calls to TempFileManager#createTempFile(...) and plug the file leak. No other code changes were necessary, and I didn’t have to wait for Sun to close the open bugs. Although not perfect, this solution does prevent temporary files from growing to the point of being a problem on a user’s system.
If you are running your application from a shell script or batch file, you could build upon this solution by also including a simple main(...) method in your implementation of TempFileManager and call it directly after your application’s JVM exits. This would clean up the temp files instantly and still maintain the lock file safety required.
This is another example of a little bug that could cause big headaches if it is not solved before a project is released. Your users will thank you and you’ll be able to sleep a little better at night knowing you won’t get a call complaining of a full hard disk—at least not one caused by this application.
