NIO: missing createTempFile() and deleteOnExit()

[Alan Bateman]

zzzzzzzzzzzzzzzzzzzz wrote:
>  
> 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.
>  
> PROPOSALS:
>  
> static File createTempFile(String prefix, String suffix)
> static File createTempFile(String prefix, String suffix, File directory) 
> ---> public abstract Path createFile(Attribute<?>... attrs) throws 
> IOException
>                   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 
welcome too.

-Alan.