FileBackedOutputStream: possibility to delete the file without File.deleteOnExit()

[GoogleCodeExporter]

The `resetOnFinalize` parameter of FileBackedOutputStream allows the client to 
specify that the file (if it was created at all) should be deleted. However, if 
you set this parameter then each file is registered for deletion at JVM 
shutdown using File.deleteOnExit().

Our applications uses many thousands instances of FileBackedOutputStream and 
the call to File.deleteOnExit() will eat resources, see 
http://stackoverflow.com/a/1506777/734191.

Could one add a parameter, for example, a parameter to specify to NOT call 
File.deleteOnExit()?

For our application, it is not tragic if some temporary files are left on the 
computer (they will be deleted on restart) but as the application is 
long-running, the use File.deleteOnExit() will cause resource leakage.

Original issue reported on code.google.com by kaspar.f...@dreizak.com on 21 Nov 2012 at 9:13

[GoogleCodeExporter]

A couple things: One, since the finalizer should run well before your JVM exits 
(assuming you're worrying about things building up over a long period of time 
before it exits) and the file should be deleted then, I would think that 
deleting the file would invalidate the deleteOnExit and any memory used by that 
would be GCed. I'm not at all sure about that, but I did want to point out that 
the situation with resetOnFinalize may be considerably different than the 
situation that stackoverflow answer is addressing.

Second, we're actually considering getting rid of the resetOnFinalize feature 
of FileBackedOutputStream entirely. It's generally not a good idea to rely on 
finalization or deleteOnExit, so it's best to find a way to handle the deletion 
directly.

Original comment by cgdec...@gmail.com on 29 Nov 2012 at 4:28

• Changed state: Research
• Added labels: Package-IO, Type-Performance

[GoogleCodeExporter]

i can testify to the dangers of deleteOnExit.  it does _not_ get cleaned up if 
the file is removed sooner, and will oome eventually if you use it in long 
running processes like a web server.  

Original comment by jp.field...@gmail.com on 11 Feb 2013 at 8:28

[GoogleCodeExporter]

On a sidenote, I use thoroughly close() to clean-up the stream. However the 
file do not gets deleted. Lokking at the source of FileBackedOutputStream it 
seems 'normal' as the files does not gets deleted in the close(). I needed to 
override the class in order to implement that.

However I think it should delete the file on the close(). What do you think ? 
Will it be in a future release ?

Original comment by jerome.b...@gmail.com on 7 May 2013 at 1:07

[GoogleCodeExporter]

close() just indicates you're done writing to the output stream, not that 
you're done with the buffered data (which you typically want to use elsewhere 
through the InputSupplier once you're done writing). That's why there's a 
separate reset() method that will delete the file/buffer.

Original comment by cgdec...@gmail.com on 7 May 2013 at 2:07

[GoogleCodeExporter]

We want to get rid of the finalization in FileBackedOutputStream.

Original comment by kak@google.com on 22 Aug 2013 at 11:33

[GoogleCodeExporter]

"... close() just indicates you're done writing to the output stream" this may 
not be the original intention of close() in streams. Pls take a look at 
definition here 
http://docs.oracle.com/javase/6/docs/api/java/io/OutputStream.html#close(). Not 
cleaning up on close in future may also not be compatible with Java 7 
Closeable. I think I understand your idea of having data available after 
writing is over however this breaks the OutputStream contract. Sorry.

Original comment by che...@gmail.com on 11 Feb 2014 at 5:23

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:18

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit