[ 
https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niklas Gustavsson closed FTPSERVER-119.
---------------------------------------

    Resolution: Fixed

Fixed in rev 734241, please verify if this fixes your problem.

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

Reply via email to