You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-dev@incubator.apache.org by Mark Proctor <li...@markproctor.com> on 2007/01/04 00:33:45 UTC
Re: ftp server and upload events
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: ftp server and upload events
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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() );
Hey Mark,
I think the following code should work for you. Note that it checks to
see if we're using the native file system. if we're not you pretty
much screwed as there might not be a File at all (it might be a
database record or a JMS message instead).
FileSystemView fsview = session.getFileSystemView();
FileObject theFileObject =
fsview.getFileObject(request.getArgument());
if (theFileObject instanceof NativeFileObject) {
NativeFileObject nativeFileObject = (NativeFileObject)
theFileObject;
File theFile = nativeFileObject.getPhysicalFile();
} else {
// sorry, don't know how to get the file from this type of
file system
}
/niklas
Re: accessing Files from an FtpLet
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
accessing Files from an FtpLet
Posted by 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
>>
>>
>
>