I'm wondering if using close() is the correct approach for you anyway.
What actions should be taken if the file wasn't completely transferred? Do
you still want to upload the file to the backend server? In your case I'm
assuming that you do not accept partial downloads ...
Since the ftpserver cannot know if the transfer ended successfully, you
might need an additional step where the client signals that it has
completed. Would that be neccessary?
In any case I agree that we should discuss (if anyone has a problem with
exceptions being propagated) how to face close() exceptions
This would be nice, would be a good way to implement storage quotas
restrictions for user accounts.
From: Niklas Gustavsson [mailto:nik...@protocol7.com]
Sent: January-12-09 2:36 PM
Subject: Re: Modifying STOR response on upload
On Mon, Jan 12, 2009 at 8:14 PM, Niklas Therning <nik...@trillian.se>
This is actually what I have done. I have implemented my own
The OutputStream returned by my FtpFile implementation will submit the
uploaded data to my backend when close() is called on it. I had hoped
that if my close() throws an exception then FtpServer would send a
negative response to the client. But it turned out the exception is
swallowed by IoUtils.close().
Yeah, you would have to throw the exception during the actual transfer.
Which, might not be feasible. However, us eating the exception on close has
been discussed before
(https://issues.apache.org/jira/browse/FTPSERVER-119) and if no-one
I would be happy to move forward on this issue so that we treat an
on close as an error during the transfer (and thus returns an error code to
the client). I'll do this for the next release unless someone screams out