2010/6/14 Chuck Johnstone <[email protected]>: > That sounds quite reasonable. I'll take a look at using FtpFile.
Other projects you might find worth looking at are Apache Commons VFS and COTTA file system. These two have a File API which seems nicer/more extensible than java.io.File > 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 >>> >>> >>> >>> >> >> > >
