New user : edtFTPj impressions/problems

Question

I tried edtFTPj out yesterday because I want to investigate moving from the limited FTP support in Apache Commons Net to a better library with SFTP and FTPS support. At first however I am focusing on std FTP functionality.

Overall edtFTPj seems to work well but I identified some issues:
1) No way to safely check if a directory on the server exist. Instead I have to attempt to change to the directory in question, catch exceptions and interpret an exception it as if the directory does not exist (which is not a sure thing). This is much easier in Apache Commons Net.
2) I found no easy way to safely check for capabilities - f.x. if setModifiedTime is supported on a given server or if the server support wildcards for directoryList ?
3) No isFile method (but remoteFile.isDir() and remoteFile.isLink())
4) The api documentation is not always clear. F.x. Will directoryList fail in certain locales like dirDetails will (that would be a big problem).

Besides, since edtFTPj supports old legacy JDK1.2 I wonder if edtFTPj in any way uses the improved socket support in java 1.4+ such as specifying socket timeouts and IPv6 etc. ?

/Morten

Answer 1

Thanks for your feedback. It is always useful to get, particularly if someone has been using the Apache FTP library and can give a comparison. Comments below.

1) No way to safely check if a directory on the server exist. Instead I have to attempt to change to the directory in question, catch exceptions and interpret an exception it as if the directory does not exist (which is not a sure thing). This is much easier in Apache Commons Net.

Yes, a directory exists method could be useful. We'll look into adding a method for this.

2) I found no easy way to safely check for capabilities - f.x. if setModifiedTime is supported on a given server or if the server support wildcards for directoryList ?

In our experience you've got to try them to see if they work. You can't rely on FEAT etc. However any suggestions welcome.

3) No isFile method (but remoteFile.isDir() and remoteFile.isLink())

I guess that can be added ( !remoteFile.isDir() && !remoteFile.isLink() )

4) The api documentation is not always clear. F.x. Will directoryList fail in certain locales like dirDetails will (that would be a big problem).

Can you clarify what you mean here? directoryList() will produce the same result as dirDetails(). Given the wrong locale (e.g. if it is English and the server is returning a German locale) you may get problems (as the months can't be read).

Besides, since edtFTPj supports old legacy JDK1.2 I wonder if edtFTPj in any way uses the improved socket support in java 1.4+ such as specifying socket timeouts and IPv6 etc. ?

We support 1.4 socket timeouts (which is done via reflection).

Answer 2

Thanks for your kind and fast reply! I appreciate it.

>Yes, a directory exists method could be useful. We'll look into adding a method for this.

Would be good. I noticed that several people on this forum also asked about this feature

>I guess that can be added ( !remoteFile.isDir() && !remoteFile.isLink() )

Yes that is what I concluded also. It is just strange that isFile is missing as this would be clearer/better.

>In our experience you've got to try them to see if they work. You can't rely on FEAT etc. However any suggestions welcome.

I assume you have tested your library against a large number of FTP servers. Thus I guess it would be easy for you to include a whitelist of known FTP servers that support which advanced features and let your library identify the server and check automatically. Of cause this would not solve the problem with unknown servers but it would be a great step forward.

>Can you clarify what you mean here? directoryList() will produce the same result as dirDetails(). Given the wrong locale (e.g. if it is >English and the server is returning a German locale) you may get problems (as the months can't be read).

I need to get a listing of all files and subdirectories for a given directory. I need to be able to iterate the result and decide what action to take depending on the entry being a file or a directory or a link. For this I need directoryList which returns FTPFile's. It is not important that the associated dates are correct but the directoryList call must NEVER fail if the dates can't be parsed (i.e. german locales). So any such problems needs to be safely ignored/handled. If I can't do that with edtFTPj(pro) then the lbirary is unusable (for me). So this is a CRITICAL issue!!

>We support 1.4 socket timeouts (which is done via reflection).

Great! What about the other new Java 1.4, 1.5, 1.6 socket features ?

P.S. Thanks for the positive dialog about my edtFTPj impressions/problems

/Morten

Answer 3

Just to follow up:

1. We plan to add a directory exists method. Hopefully next release.
2. We'll add isFile() (next release)
3. Not sure about feature detection. Using a whitelist of FTP servers isn't practical for us - the same FTP server could easily be configured to support certain features or disable them. Undecided.
4. We plan to add a switch that will turn off date parsing exceptions in directoryList(). Next release.

You'll need to elaborate on what Java 1.4+ socket features you would like added.

Answer 4

Oops, I forgot that date parsing errors should no longer be thrown - this was implemented a little while ago. The date will just be set to null. If you experience otherwise please let us know.