You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Frank (JIRA)" <ji...@apache.org> on 2008/03/28 17:08:24 UTC

[jira] Created: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

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
         Environment: na
            Reporter: Frank
            Priority: Minor


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.


[jira] Commented: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

Posted by "Niklas Gustavsson (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Updated: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

Posted by "Niklas Gustavsson (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Niklas Gustavsson updated FTPSERVER-119:
----------------------------------------

    Fix Version/s: 1.0.0-RC2
         Assignee: Niklas Gustavsson

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


[jira] Commented: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

Posted by "Niklas Therning (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663243#action_12663243 ] 

Niklas Therning commented on FTPSERVER-119:
-------------------------------------------

I recently ran in to the same problem and asked about it on the users mailing list: http://markmail.org/message/gki55y2xvybogknh

> 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
>            Priority: Minor
>
> 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.


[jira] Commented: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

Posted by "Niklas Gustavsson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586175#action_12586175 ] 

Niklas Gustavsson commented on FTPSERVER-119:
---------------------------------------------

So, if I understand your request, you would like us to send a "551 Error on output file" error message in an exception is thrown during close? If so, please start a discussion on the dev list (dev@mina.apache.org) as it might affect other people, just to make sure we do the right thing.

> 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
>         Environment: na
>            Reporter: Frank
>            Priority: Minor
>
> 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.


[jira] Commented: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

Posted by "Frank (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FTPSERVER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666461#action_12666461 ] 

Frank commented on FTPSERVER-119:
---------------------------------

Thanks a lot, I'm just wondering if you shouldn't do it before you update the statistics. If the close fails then the transfer should be considered failed in the statistics too I think.

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


[jira] Closed: (FTPSERVER-119) STOR command should not eat exceptions when closing stream

Posted by "Niklas Gustavsson (JIRA)" <ji...@apache.org>.
     [ 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.