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 2009/1/12 Dan <[email protected]> > This would be nice, would be a good way to implement storage quotas > restrictions for user accounts. > > Dan > > -----Original Message----- > From: Niklas Gustavsson [mailto:[email protected]] > Sent: January-12-09 2:36 PM > To: [email protected] > Subject: Re: Modifying STOR response on upload > > On Mon, Jan 12, 2009 at 8:14 PM, Niklas Therning <[email protected]> > wrote: > > This is actually what I have done. I have implemented my own > FileSystemView. > > 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 > objects, > I would be happy to move forward on this issue so that we treat an > exception > 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 > loud :-) > > /niklas > >
