[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18009486#comment-18009486
 ] 

Stephan Markwalder commented on FILEUPLOAD-295:
-----------------------------------------------

Hi [[email protected]] 

Sorry for the late reply. I was traveling for some time.

I had a look at the new state model and code in {{master}} and I like it a lot. 
I find the code much easier to understand and validate. Initially, I was 
surprised by the decision to create an own {{DeferrableOutputStream}} instead 
of relying on Commons IO. But after reading the explanation in JavaDoc and 
thinking about this once more, I think this is the right way to go.

We do plan to migrate our web application to the Jakarta namespace in Q4 2025. 
This will be the perfect moment to upgrade to Commons FileUpload 2. I'm already 
looking forward to this. The configuration with _threshold = -1_ will probably 
the one we will go for.

PS: The 3 links to FILEUPLOAD-295 in the JavaDoc in {{DiskFileItemTest}} are 
missing a digit in the link display name: 
{{[...]/{color:#00875a}FILEUPLOAD-295{color}">{color:#FF0000}FILEUPLOAD-29{color}</a>}}

> DiskFileItem: getStoreLocation() may return non-existing file
> -------------------------------------------------------------
>
>                 Key: FILEUPLOAD-295
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-295
>             Project: Commons FileUpload
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: Stephan Markwalder
>            Assignee: Jochen Wiedmann
>            Priority: Minor
>
> *How to reproduce*
>  # Create a DiskFileItem with threshold set to -1 (force save to disk).
>  # Get OutputStream from DiskFileItem.
>  # Close OutputStream without calling any write(...) method (e.g., because 
> the uploaded file is empty).
>  # Test the return value of the following methods:
>  ** isInMemory() --> returns false (OK)
>  ** getSize() --> returns 0 (OK)
>  ** getStoreLocation() --> returns a File object (OK), but the file does not 
> exist (FAILURE).
> I think this is an inconsistency. If isInMemory() returns false adn 
> getStoreLocation() returns a File object, the file should also exist.
> Java code (run with -ea to enable assertions):
> {code:java}
> // create a DiskFileItem
> int sizeThreshold = -1; // always store to disk
> File repository = null; // use temporary folder
> DiskFileItem item = new DiskFileItem("file", "text/plain", false, "file.txt", 
> sizeThreshold, repository);
> OutputStream outputStream = item.getOutputStream();
> // do not write to stream <-- IMPORTANT
> outputStream.close();
> // assert that data has been stored to disk
> assert !item.isInMemory(); // pass
> assert item.getSize() == 0; // pass
> assert item.getStoreLocation() != null; // pass
> assert item.getStoreLocation().isFile(); // fails
> {code}
> When adding a call to outputStream.write(new byte[0]), the behavior changes 
> and the empty file is created on disk.



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

Reply via email to