I don't feel very comfortable with the idea of running ls (although I'm executing several ln -s and I'm fine with it :P) for the output, although users can reimplement any command they like ... :-) but it doesn't look that useful, having into account that file permissions won't be applicable when using ftpserver.
Besides, the filesystem interface abstracts the real filesystem, using "ls" would only be possible with the nativefilesystem implementation. Following Niklas idea we might get "extended info" fromt the filesystem by using Apache Portable Runtime ... But i don't know if it is worth it. We can always wait for NIO2. I would like to implement a "permission system" where a FTPUser is allowed or not to modify a file, retrieve it etc. Do you have any ideas on this ?? I'm thinking that it's difficult that we can implement a "Native" version which uses the system privileges ( I think SSHD project did something like this, since it logged through the PAM system ... but we can't do this having not different threads for different connections, right? ) I guess we should use a file format ( or database table ) where the permissions for the different files/ directories are stored. Since many applications should have their own ACLs , do you know of any format that we may use ? 2009/6/2 Niklas Gustavsson <nik...@protocol7.com>: > On Tue, Jun 2, 2009 at 12:21 PM, Sai Pullabhotla > <sai.pullabho...@jmethods.com> wrote: >> In any case, what if we give an option for running a native command when >> NLST or LIST command is received. So, the user could configure the FTP >> server to execute the ls command and we redirect the output of the ls >> command back to the client. One of the advantages of allowing this for the >> LIST command is we can actually return more information about files and >> directories such as if an object is symbolic link, the owner etc. (of course >> applicable mainly to *NIX systems) which cannnot be retrived using Java. >> Something to think about. > > There has been some discussions around this previously, especially to > be able to get hold of the user/group information. However, no one has > come up with an implementation. Personally, I don't think an > implementation based on running processes is a very good idea since it > would likely affect both the performance and stability of the server. > That being said, since this would be isolated to the file system, > anyone could create an implementation, even if we did not ship it with > FtpServer core. > > A more refined solution might be to use JNI rather than running > processes, but that's beyond my competence :-) > > /niklas >
