NIO: missing createTempFile() and deleteOnExit()
Alan.Bateman at Sun.COM
Wed May 28 05:45:40 PDT 2008
> I'm very interested to play with the NIO in the fields of portable
> applications to use it for encrypted filesystems in a singel file and
> so on. To port existing applications and dbs it would be nice to have
> two more things in the NIO: createTempFile() and deleteOnExit().
> If I missed it in the existing NIO please give me a hint.
> Otherwise my proposals just need very little modification of the
> existing interfaces.
> static File createTempFile(String prefix, String suffix)
> static File createTempFile(String prefix, String suffix, File directory)
> ---> public abstract Path createFile(Attribute<?>... attrs) throws
> with Attributes for prefix, suffix [and directory]
> ( or by breaking the existing interface
> ---> public abstract Path createTempFile(...) throws IOException )
> void deleteOnExit()
> ---> public static final StandardOpenOption DELETE_ON_EXIT
(I've moved this to nio-discuss as that is the mailing list for feedback)
Thank you for bringing up these topics. The summary answer is that they
aren't present but they aren't forgotten either.
You've suggested adding a DELETE_ON_EXIT option to the standard open
options. I may be reading too much into this but did you mean
DELETE_ON_CLOSE instead? A delete-on-close option may be useful but it's
not supported on many operating systems and isn't really feasible to
implement without support from the kernel (deleting the file after close
isn't exactly the same thing as the file may have been replaced by an
attacker and so we would delete the wrong file). If you mean the File
deleteOnExit method then you are correct that this isn't an equivalent.
Arguably we haven't really needed the delete on exit mechanism since the
addition of the shutdown hooks in 1.3. The shutdown hooks allow for
other types of tasks in addition to removing individual files before the
VM shuts down. They can also be cancelled which is something that isn't
(currently) possible with the delete mechanism. Another point is that
with the provider interface there is potential for other types of file
systems and it may be that you want is for the file to be registered for
deletion when the FileSystem is closed (VM exit is too late). More
generally you may have tasks to perform before the file system is
closed. It would be good to get more feedback in this area so that we do
the right thing.
As regards temporary files: File.createFile(prefix,suffix).getFileRef()
creates a temporary file and gives you an object in the new API to
access that file. If you are instead asking about creating temporary
file in a given FileSystem then we currently don't have a method to do
that, unless of course you choose the temporary file name yourself and
invoke createFile. The notion of "temporary directory" is traditionally
something that is configured for the platform rather than a per-file
system basis. It could be extended of course so feedback on this area is
More information about the nio-discuss