Bug 59166

Would you be able to put together a patch together with some unit-tests that would address and verify this?

I am setting this to Enhancement for now as you can already implement your own TempFileCreationStrategy, which allows to do this differently if this is actually a problem for your application.

None of the POI unit tests run long enough to experience the problems you're experiencing. While we could register just the directory for deletion on JVM exit, this strategy seems dangerous if the directory was not empty before starting or a separate application wrote data to the directory. Under these conditions, data loss could occur.

Another strategy for long-running processes is to keep a fixed-length queue of files and delete the files FIFO as the queue overflows.
This would mean not registering deleteOnExit with the JVM, so you would need to intercept a JVM exit message to delete the files remaining in the queue before the JVM shut down.

You could also implement a strategy that deletes all temp files that have been created. This is essentially the same as above using a variable-length set that never implicitly deletes files.

I don't think any of these strategies are safe enough to implement without getting into trouble: either leaving temp files behind or accidentally deleting files that shouldn't have been deleted. If you have a better TempFileCreationStrategy that would appeal to many users, feel free to re-open this bug with the corresponding patch.

With the changes from bug 59788, the strategy described in Comment 0 could be accomplished by:

File tempDir = DefaultTempFileCreationStrategy.createTempDirectory("registeredDirectory");
for (String f : filesToAdd) {
    createSomeFile(new File(tempDir, f));
}

I updated the documentation in r1751190 to make the purpose of DefaultTempFileCreationStrategy clearer and suggestions for other TempFileCreationStrategy's that may be useful outside of the POI project.