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

[gissuebot]

Original issue created by kaspar.f...@dreizak.com on 2012-11-21 at 09:13 PM

---

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.

[gissuebot]

Original comment posted by cgdecker on 2012-11-29 at 04:28 AM

---

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.

---

Status: Research Labels: Package-IO, Type-Performance

[gissuebot]

Original comment posted by jp.fielding on 2013-02-11 at 08:28 PM

---

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.

[gissuebot]

Original comment posted by jerome.bonnet on 2013-05-07 at 01:07 PM

---

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 ?

[gissuebot]

Original comment posted by cgdecker on 2013-05-07 at 02:07 PM

---

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.

[gissuebot]

Original comment posted by kak@google.com on 2013-08-22 at 11:33 PM

---

We want to get rid of the finalization in FileBackedOutputStream.

---

Owner: cgdecker@google.com

[gissuebot]

Original comment posted by cherio on 2014-02-11 at 05:23 AM

---

"... 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.