That sounds quite reasonable.  I'll take a look at using FtpFile.

On 10-06-14 03:36 AM, Guillaume Nodet wrote:
Thinking a bit more about this, I think the following would make sense:
   * copy FtpFile and NativeFtpFile from FtpServer into the sshd subsystem
package
   * copy the SftpSubsystem to AbstractSftpSubsystem and rework it to use a
FtpFile root
   * rework SftpSubsystem to inherit AbstractSftpSubsystem and just provide a
NativeFtpFile file system root

For the long term solution, I think it would make more sense to do the work
in FtpServer and use SSH as an addition transport layer, thus reusing user
management, file system users configuration and all ...  It should be then
really simple to implement an org.apache.sshd.server.sftp.FtpFile on top of
the existing ftpserver FtpFile and provide a user authentication mechanism
delegating to the ftpserver auth mechanism.

On Mon, Jun 14, 2010 at 11:27, Guillaume Nodet<[email protected]>  wrote:


On Thu, Jun 10, 2010 at 20:19, Chuck Johnstone<
[email protected]>  wrote:

Hi,

As per the previous email I'm going to experimentally rework SftpSubsystem
to use a db backend.

My current approach is to copy SftpSubsystem and abstract out the file
access.  The new class is called AbstractSftpSubsystem.

Right now I've created an interface that mimics all the pertinent bits of
java.io.File as used in SftpSubsystem.

The interface currently looks like this:

    public static interface SftpFile { // from java.io.File
        boolean exists();
        boolean createNewFile();
        SftpFile getParentFile(); // based on File.getParentFile()
        String getPath();
        long length();
        boolean canRead();
        boolean canWrite();
        boolean isFile();
        boolean isDirectory();
        long lastModified();
        SftpFile[] listFiles();
        String getName();
        boolean delete();
        boolean mkdir();
        boolean renameTo(SftpFile dest);
        SftpFile getAbsoluteFile();
    }

Yeah, looks good.  Though, we'd need to be able to read / write to those
files, which isn't possible in this interface.
I really wonder if a simplier approach would be to just copy the FtpFile
interface [1] into the subsystem package.  At least, we'd know that we'll be
able to bridge with FtpServer quite easily.

[1]
http://svn.apache.org/viewvc/mina/ftpserver/trunk/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/FtpFile.java?view=markup

I believe this is in line with the discussion so far.  If there is a
better way let me know.  I'll submit patches if you think this approach is
useful.

Cool ! Patches is the way to go ...

The good news is that my company is funding the development time.  The
above approach is our short term solution to this problem but we're also
interested in a longer term solution.  Mention was made of moving this into
apache ftpServer.  We intend to help with that too.  I've used ftpServer to
implement a backend FTPS solution so I'm a bit familiar with the system but
I'm not familiar with the details of SFTP.  I'm assuming that SFTP code from
SftpSubsystem could be ported into Mina ftpServer structures.

Well, I'm not very familiar with the FtpServer project.  I wonder if it
would be easier / cleaner to integrate SSHD into FtpServer project as an
additional transport, or integrate FtpServer into SSHD as a new backend for
SFTP subsystem.  Maybe other FtpServer people can jump in and throw some
ideas here.


I'll be focused on the short term solution over the next few weeks but
after that I can move onto the longer term solution.  Discussion/guidance in
this task will be greatly appreciated.

Chuck Johnstone



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com





Reply via email to