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