accessing Files from an FtpLet

[Mark Proctor <li...@markproctor.com>]

The more I think about this now the more I think that FtpServer should 
encapsulate this functionality, it's just one less thing for the user to 
figure out and get wrong.
String getFileName() - returns just the file name, not the path
String getPath() - returns the path from the users home directory
String getAbsolulteFilePath() - returns the complete absolute file path 
and name
File getFile() - returns a File object

Mark
Mark Proctor wrote:
> What is the most robust way to get an absolute path to the file, so 
> that  I can do new File(path) to access that file? Below seems a bit 
> flakey, but I can't think of anything better.
>
> String file = 
> request.getFileSystemView().getCurrentDirectory().getFullName();
> User user = request.getUser();
> String name = user.getName();
> String home = user.getHomeDirectory();
> if ( home.startsWith(".") ) {
>    home = home.substring( 1 );
> }
>
> File file = new File(  System.getProperty("user.dir") + home + file + 
> request.getArgument() );
>
>
> Mark
>
> Knutsen Rolf Aslak wrote:
>> In the onUploadEnd you get the FTPRequest Object.
>>
>> The getArgument will give you the current uploaded filename.
>> The request.getFileSystemView().getCurrentDirectory().getFullName() will
>> give you the directory the user is in.
>>
>> In onUploadEnd:
>>
>>     System.out.println("Argument: " + request.getArgument());
>>     System.out.println("CurrDir:  " +
>> request.getFileSystemView().getCurrentDirectory().getFullName());
>>
>>
>> FTP Client: ------------------------
>> Connected to local.
>> 220 Service ready for new user.
>> User (local:(none)): admin
>> 331 User name okay, need password for admin.
>> Password:
>> 230 User logged in, proceed.
>> ftp> cd test
>> 250 Directory changed to /test
>> ftp> put pom.xml
>> 200 Command PORT okay.
>> 150 STOR
>> 226 Data transfer okay.
>>
>>
>> FTP Server:
>> -----------------------
>> ------- Apache FTP Server started ------
>> Open connection - 127.0.0.1
>> Login success - admin
>> Argument: pom.xml
>> CurrDir:  /test
>> Close connection : 127.0.0.1 - admin
>>
>>
>> Combinding those should give you access.. ???
>> -Aslak Knutsen
>>
>> -----Original Message-----
>> From: Mark Proctor [mailto:lists@markproctor.com] Sent: 31. oktober 
>> 2006 15:32
>> To: ftpserver-dev@incubator.apache.org
>> Subject: Re: ftp server and upload events
>>
>> Can anyone provide an insight into this?
>>
>> We want to automate the handling of incoming files. We have something
>> hacked now, which is a hard coded singleton in the ftp server code that
>> broascasts events, but looking for the correct way to do this.
>>
>> Mark
>> Mark Proctor wrote:
>>  
>>> Is there an existing way to hook into an upload event so I can 
>>> reforward a file  as an event? I've looked at the ftplet and while 
>>> it emits events when the upload is finished, it does not expose the 
>>> actually file it uploaded only a stream. I'm guessing if I re-opened 
>>> the stream it would either fail or re-stream it from the client, 
>>> both undesired effects.
>>>
>>> If this is currently not possible I'm thinking of either adding a 
>>> new param to the event that passes the File, or introduce a whole new
>>>     
>> event.
>>  
>>> Mark
>>>     
>> -- 
>> This email has been verified as Virus free
>> Virus Protection and more available at http://www.plus.net
>>
>>   
>
>

Re: accessing Files from an FtpLet

[Niklas Gustavsson <ni...@protocol7.com>]

Mark Proctor wrote:
> Niklas,
> 
> The method names where just illustrative, and I know some of them where 
> already provided - was just trying to think of a unified api that made 
> sense for file handling. I see your issue about AbsolutePath, didn't 
> know about NaitveFileSystemView and eventually I'd want an in memory 
> view anyway, so agreed I see the problems there. Maybe some URL like 
> openStream() method for a unversal way to read in the file? In my case I 
> just want a full proof way to read in the file and send it somewhere 
> else, and this would provide thatregardless of the underlying storage.

Hopefully we beat you to it :-)

FileObject.createInputStream()

/niklas

Re: trunk is b0rked

[Niklas Gustavsson <ni...@protocol7.com>]

Mark Proctor wrote:
> Someone has done some refactoring and left ftpserver-admin-gui b0rked, 
> its still reference stuff in org.apache.ftpserver.interfaces.* which are 
> no longer there.
> 
> Mark
> 

Sorry, my bad! Should be fixed now. My Eclipse install sometimes looses 
track of changes between dependent projects :-/

I'm going to try get us a CI server running our builds which should 
catch stuff like this.

/niklas

trunk is b0rked

[Mark Proctor <li...@markproctor.com>]

Someone has done some refactoring and left ftpserver-admin-gui b0rked, 
its still reference stuff in org.apache.ftpserver.interfaces.* which are 
no longer there.

Mark

Re: accessing Files from an FtpLet

[Mark Proctor <li...@markproctor.com>]

Niklas,

The method names where just illustrative, and I know some of them where 
already provided - was just trying to think of a unified api that made 
sense for file handling. I see your issue about AbsolutePath, didn't 
know about NaitveFileSystemView and eventually I'd want an in memory 
view anyway, so agreed I see the problems there. Maybe some URL like 
openStream() method for a unversal way to read in the file? In my case I 
just want a full proof way to read in the file and send it somewhere 
else, and this would provide thatregardless of the underlying storage.

Mark


Niklas Gustavsson wrote:
> Mark Proctor wrote:
>> The more I think about this now the more I think that FtpServer 
>> should encapsulate this functionality, it's just one less thing for 
>> the user to figure out and get wrong.
>> String getFileName() - returns just the file name, not the path
>> String getPath() - returns the path from the users home directory
>> String getAbsolulteFilePath() - returns the complete absolute file 
>> path and name
>> File getFile() - returns a File object
>
> I would have to say that I object to these. The reasons below:
>
> String getFileName() - this would be the same value as 
> FtpRequest.getArgument(), right?
> String getPath() - this should, and already is, part of the file 
> system interfaces, FileSystemView.getCurrentDirectory(). Wouldn't that 
> be sufficient?
> String getAbsolulteFilePath() and File getFile() - this would make the 
> assumption that you really got a traditional file system backing the 
> FileSystemView. This is the case with NativeFileSystemView in which 
> case we provide this method, getPhysicalFile(). It's not the case when 
> you, for example, got a database backing a file system.
>
> I did send an earlier reply to your questions but it seems to got 
> stuck somewhere, I'll resend it.
>
> /niklas
>
>

Re: accessing Files from an FtpLet

[Niklas Gustavsson <ni...@protocol7.com>]

Mark Proctor wrote:
> The more I think about this now the more I think that FtpServer should 
> encapsulate this functionality, it's just one less thing for the user to 
> figure out and get wrong.
> String getFileName() - returns just the file name, not the path
> String getPath() - returns the path from the users home directory
> String getAbsolulteFilePath() - returns the complete absolute file path 
> and name
> File getFile() - returns a File object

I would have to say that I object to these. The reasons below:

String getFileName() - this would be the same value as 
FtpRequest.getArgument(), right?
String getPath() - this should, and already is, part of the file system 
interfaces, FileSystemView.getCurrentDirectory(). Wouldn't that be 
sufficient?
String getAbsolulteFilePath() and File getFile() - this would make the 
assumption that you really got a traditional file system backing the 
FileSystemView. This is the case with NativeFileSystemView in which case 
we provide this method, getPhysicalFile(). It's not the case when you, 
for example, got a database backing a file system.

I did send an earlier reply to your questions but it seems to got stuck 
somewhere, I'll resend it.

/niklas