[jira] [Created] (CODEC-319) DeferredFileOutputStream does not delete the temporary file created

["Sheung Chi Chan (Jira)" <ji...@apache.org>]

Sheung Chi Chan created CODEC-319:
-------------------------------------

             Summary: DeferredFileOutputStream does not delete the temporary file created
                 Key: CODEC-319
                 URL: https://issues.apache.org/jira/browse/CODEC-319
             Project: Commons Codec
          Issue Type: Improvement
            Reporter: Sheung Chi Chan


The {{DeferredFileOutputStream}} class is a custom {{OutputStream}} object from the Apache Commons IO library which will not write data directly to disk. It will only write data to disk when the configured threshold is reached. During the initialisation of the {{DeferredFileOutputStream}} object through its builder class, the user could specify a custom file path or provide a prefix and suffix for temporary file creation. The provided custom file path or the temporary file created will be used for storing the data on disk when the configured threshold is reached. When using the prefix/suffix approach, the temporary file is created using the {{java.nio.file.Files::createTempFile}} method only when the threshold is reached. The temporary file created by the {{java.nio.file.Files::createTempFile}} method will not be removed automatically, thus when the stream is closed after the threshold is reached and the prefix/suffix approach is used, there will be an unexpected file stored in the disk persistently. Although it should not be accessible by other users since the {{java.nio.file.Files::createTempFile}} method creates a temporary file only for the current user to access, it still poses a problem when the {{DeferredFileOutputStream}} object is being flooded with a large amount of data. This could use up the disk space and cause possible out-of-disk space problems.

Although the flooding of data could also be a problem when using the user-provided file, since it is the user who creates the file, thus the user is responsible to remove or clean up that file when it is no longer used. But if the prefix/suffix approach is used, the user does not have control of the file and when the {{DeferredFileOutputStream}} is closed, it is assumed that the temporary file created during the processing of {{DeferredFileOutputStream}} is removed or cleaned up. It is a general practice for Java OutputStream to clean up its process and temporary objects when its close method is called. Thus the missing that could result in unexpectedly large files staying in the disk unawared.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)