Java version 1.2 or later hasFile.createTempFile( String prefix, String suffix, File directory) for creating uniquely named temporary files. Unfortunately you still have to manually
delete these files when you are finished with them.
Unlike C,Java version 1.1 does not have methods for generating unique temporary filenames. I have written a
getTempFile method.
Here is a slightly smarter version ofJava version 1.2 or later’s File.createTempFile() that will let you specify either a directory to create the temp file in, or
a file in whose directory to create the file in. You need the logic of this smarter version if you want to write
a utility that replaces the input file with the processed output from a renamed temp file.
I am using Vista and I am horrified to discover than even after 25 years Microsoft
still does not understand the temporary files problem.
When a program crashes, it does not delete its temporary files. Over the years your disk fills with junk.
Windows does not:
- automatically clean up orpdaned temporary files after a crash.
- mark the temporary files in some way with a naming convention or attribute bit so that they can be
recognised by some batch scavenging program run periodically.
Java is just as stupid. It is time at least to at least get Java capable of cleaning up its own mess. I suggest
some official Sun format for temporary files, e.g. ~myappxxxxxxxx.temp. If all apps use
that convention, a simple scavenger program, such as Ace Utilities, can scan the disk and mindlessly delete all
*.temp files. That way you could also tell which app was leaving orphan temporaries
behind. It is a symptom of pathology.
Here are three ways we could handle the probem of orphaned temporary files:
- Java hasFile.deleteOnExit(). In theory the OS (Operating System) should note this call and do the deletions even if Java
crashes. The catch is, it doesn’t. If the app crashes, the Java runtime won’t necessarily be alive
to do the deletions.
- The Linux way. More intelligent operating systems such as Linux and FreeBSD tend to clean /tmp and /var/tmp
during the initial stages of a reboot, or, if one uses tmpfs, the issue doesn’t even arise since tmpfs is
purely RAM-based and is wiped when the machine reboots.
To use tmpfs, make sure your kernel can handle 'tmpfs', then add the following line into
/etc/fstab:
tmpfs /tmp tmpfs noatime,mode=1777 0 0 then either reboot or 'init s’
then 'init {runlevel}', depending on preferences and OS configuration. (Don’t just mount /tmp
unless you’re sure nothing is using it. X in particular sticks files in there —
/tmp/.X11-unix/Xn, presumably for its Unix sockets.)
- In a sane OS, temporary should be an attribute bit on the file the OS maintains.
The OS could then automatically delete any file with that attribute not currently in use. Then you would need
ways in each language to set the attribute. Java could access the attribute with a native method called by
File. createTempFile(). For debugging, you could
configure the OS scavenging to delay 24 hours to give you time to analyse the
temp files after a crash. An app that terminated normally would automatically have all its temp files deleted,
even if the app itself failed to do that. Vista now supports a temporary file attribute, but it does not
automatically delete such files. You must run a utility periodically to find and delete them.
- What I do myself is name temporary files as tempxxxxxxxxx.tmp. This makes orphans
easy to identify, and makes it clear even to a casual observer the file in an orphaned temporary. It might be
good to include the app name in there somewhere, e.g. temp-whazmo-xxxxxxxxx.tmp. so
you know which app is malfunctioning.
We more that just a convention. If the OS knew a file were a temp it would know to place it in prime real
estate, perhaps even on an SSD or virtual RAM (Random Access Memory). It could
automatically clean it up. Backup software would automatically avoid backing up such files.