Re: return to the begin of InputStream
Martin Gregorie wrote:
On Sat, 05 Dec 2009 10:11:30 +0000, Tom Anderson wrote:
Although this still doesn't handle crashes. I think there is a trick you
can do on unix to have files deleted even when the process crashes -
something like create, open, then delete the directory entry, so that
the only reference keeping the file alive is from the open filehandle,
which will die when the process exits - but i don't know if there's a
way to use it from java. Or even that this is definitely correct.
Thats correct. Its the standard UNIX idiom for making sure that temporary
files don't outlive the process that created them no matter how it dies.
It should work from Java since its not language-dependent, though of
course its not portable outside outside the *nix world.
However, by default, createTempFile puts files in java.io.tmpdir, which
on unix machines will typically be /tmp. Files there are subject to
deletion at the whim of the OS, so to an extent, you can delegate the
problem of worrying about deleting files to that.
You should attempt to delete them at some stage because there's no
guarantee that the OS will. Its merely a way of guaranteeing that the
tempfile has a unique name no matter how many copies of the process are
running.
A more useful approach would be to start the process(es) from a shell
script or control process whose first action is to delete all temporary
files it finds that are used by the processes it controls: this will be
portable provided the script/control process is portable: no reason it
shouldn't be written in Java or a portable scripting language like Groovy
or Python.
That said, i'm not sure what current unixen's policies towards /tmp are;
i believe linux will only delete things at reboot, not during normal
operation, which makes this less useful.
I'm not certain that temp files are necessarily deleted at boot because
that does slow down crash recovery. Since a file in temp will survive
until its closed, its equally likely that there's a cron job that runs
'rm -rf /tmp/*' sometime after midnight each day. The real caveat is that
no program creating files in /tmp should expect them to be there after it
terminates, i.e. don't pass them to another program started after the
first ends.
(Marginally topical) On Solaris, the Unix flavor I'm most
familiar with, /tmp is usually mounted on a tmpfs file system.
This is a memory-resident file system to the extent possible,
spilling over into swap space as needed. Nothing special needs
to happen at reboot to "clean out" tmpfs, no more than anything
special needs to happen to "clean out" swap files: The newly-
booted system just initializes its metadata to say "empty," and
everything from prior incarnations is gone.
Also, it's a *very* bad idea to purge /tmp blindly, even if
you're careful only to purge files that haven't been modified
in a while. I recall working with a server application that put
files in /tmp and mmap'ed them to share memory between its multiple
processes. Since simple paging I/O to and from a file opened a
week ago doesn't change the files' modification date, along came
the customer's /tmp-purging cron job and BLOOEY went the server ...
--
Eric Sosman
esosman@ieee-dot-org.invalid