Frank,
The better solution is to add support for close() and open().
I added file open() and close() to the ftplet.FileObject interface. This
is to better support a virtual file system. For the native file system
this does not make too much sense, but for others it does. The open()
and close() can be thought of as an opportunity to pre-process or
post-process a stream file.
In my case I need to update some of the metadata information after the
file was written via a stream. So I added the close() in the final
statement of specific commands [see below].
From this:
finally {
IoUtils.close(os);
}
To this:
finally {
IoUtils.close(os);
file.close();
}
Then in my implementation of FileObject:
public void close() {
...
// do some post-write operations
File f = new File(fileName);
long fsize = f.getLength();
...
}
The list of commands that would need to be changed to support the
close() method are:
APPE
MD5
RETR
STOR
STOU
The classes of interest are:
ftplet:
org.apache.ftpserver.ftplet.FileObject
core:
org.apache.ftpserver.command.APPE
org.apache.ftpserver.command.MD5
org.apache.ftpserver.command.RETR
org.apache.ftpserver.command.STOR
org.apache.ftpserver.command.STOU
---
Hopefully this is useful. I made more changes to make the file system
interface(s) more "virtual", ie, support for multiple volumes and so
forth. Once I am sure all is good, I am to submit them to Niklas to see
if there was any interest in making them part of the project.
My purpose for the changes was to make the FTPSERVER file system not
care where the metadata and file content were located at. In my case
they are far apart, one is in a database, the other is somewhere else,
sometimes local, sometimes on a different storage device [like a Centera].
I did not look at your implementation yet, so maybe the above does not
apply.
Andy
Frank van der Kleij wrote:
I am using the Mina FTPServer together with Apache Commons VFS to provide FTP
access to the Documentum CMS. I created an alternative file system manager
implementation for the FTPServer to bridge to the VFS (more details can be
found at http://dctmvfs.sourceforge.net/ftpserver-vfs). Documentum access is
realized using a plugin for VFS
To import in Documentum I need to work with files, while the FTP (and VFS)
interfaces work with streams. I solved this by using a handler on the close
event of the stream that does the actual import. Since all kinds of errors can
occur, these errors arrive in the FTP server on the close method on the stream,
which are ignored for the moment.
FTP clients therefore think the transfer was successful.
Since I think the close is a major event in interfaces like this, I suggest to
stop ignoring the possible exceptions. For for example by adding a close on
the stream right after the method that uses the stream and to only ignore
exceptions on a close in the finally block.
The exact error message that should be sent can be a 551 as is the current
IOException handling; but perhaps there are better options, I'm not too
familiar with FTP error codes.
Does anyone have any comments?
Best regards,
Frank
Below, I've put my original JIRA request and Niklas Gustavssons comment.
Date: Sun, 6 Apr 2008 13:20:25 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [jira] Commented: (FTPSERVER-119) STOR command should not eat
exceptions when closing stream
[ 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 ([email protected]) 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.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
