[
https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667081#action_12667081
]
Niklas Gustavsson commented on FTPSERVER-119:
---------------------------------------------
Agreed, I'll open a new JIRA for this and schedule it for 1.0.1
> STOR command should not eat exceptions when closing stream
> ----------------------------------------------------------
>
> Key: FTPSERVER-119
> URL: https://issues.apache.org/jira/browse/FTPSERVER-119
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.0.0
> Environment: na
> Reporter: Frank
> Assignee: Niklas Gustavsson
> Priority: Minor
> Fix For: 1.0.0-RC2
>
>
> When the STOR commands closes the outputstream, it uses
> IOUtils.close(OutputStream) in a finally block which eats all exceptions.
> Wouldn't it be possible to first do a normal close on the stream after
> dataConnection.transferFromClient(outStream) and only eat exceptions on close
> in the finally block?
> Is there a reason for always eating close exceptions?
> If you consider changing it, would you also do it on branch1.4?
> I'll describe my motivation below:
> I have created a custom FileSystemManager based on Commons VFS. One of the
> VFS plugins I use stores the output stream temporarily as a file and then
> further handles the file when close is called on the output stream.
> When something goes wrong passing the file to lower levels an exception is
> thrown, but the exception gets eaten by IOUtils.close and a success message
> is sent to the FTP client. FileZilla for example already shows the file being
> transferred since it doesn't do a new directory listing, so for users it's
> quite difficult to find failed transfers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
