SecureFileTransferClient connection to server which blocks pwd

Question

The server that we connect to has disabled the use of pwd on their side.  When using the SecureFileTransferClient we have discovered that on connect() the pwd command is issued after the connection is made.  Also, when doing a changeDirectory the pwd command is also issued.  Is there a way to not have the pwd command issued after every command?

Answer 1

I've never heard of that before, so, no, unfortunately that's not an option we've implemented.  However, SecureFileTransferClient is a high level, more user-friendly class that uses the lower level SSLFTPClient for all of the actual FTP operations (and SSHFTPClient for SFTP).  I suggest that you port your code from using SecureFileTransferClient to SSLFTPClient.  This gives you near-total control over which commands are sent to the server.

Comments

I tried writing a simple SSLFTPClient to connect, change directory and put a file.  My code looks like this:
SSLFTPClient client = new SSLFTPClient();
client.setValidateServer(false);
client.setRemoteHost(host);
client.connect();
client.login(user,password);
client.chdir("test");
client.put("a.a","a.a");
client.quit();

With the logging level set to DEBUG, I see the connect, the login and then a PWD command is issued.  The chdir command is done and then another PWD is issued.  The final things are the STOR and then the disconnect.

A snippet from the log looks like this:
DEBUG [FTPControlSocket]  (date)  ---> CWD test
DEBUG [FTPControlSocket]  (date)  250 Directory successfully changed.
DEBUG [FTPControlSocket]  (date)  ---> PWD
DEBUG [FTPControlSocket]  (date)  257 "/test"

The FTPControlSocket seems to issue a PWD command after the login and the chdir command.  Is there a way to turn this off?

---

It does, but if an error is returned by the server it is ignored.

---

With the SecureFileTransferClient, the PWD that was sent with the connect command would kill the connection.  I haven't tried with the SSLFTPClient, so I'm not sure if the behavior is the same with that client.  

I read on a different thread that connecting first and then logging in would not cause a PWD to be sent to the server during the connect.  I'm still seeing it though when running the above code.  We would be OK with the PWD after the chDir being ignored and not severing the connection, but the PWD in the connect kills us.

---

Unless I missed something, the SSLFTPClient.put(InputStream,String) method doesn't execute a PWD command before starting the transfer, so please try this instead:

client.put(new FileInputStream("a.a"),"a.a");

Note that this put method closes the stream after the transfer.

---

By the way, we've been answering questions like yours for over 15 years and sometimes we find that users are expecting our software to deal with servers that are so 'unconventional' that, really, they're just faulty.  Yours is very close to that.  I can't see any reason why a server should drop a connection when a client tries to execute a PWD command.  Can you?  If not, then the server is just broken and the onus should be on the server admins to fix it.  In any case, try what I suggested.  It should work.

---

There isn't a PWD issued after the put.  We see the PWD come after the connect and after the chDir().  The one that comes after the connect ends up breaking the connection.  

For whatever reason, the policy on the server is to disallow the PWD command (I assume they don't want users to glean their directory structure).   I agree that it is a bad setup, but one we are forced to deal with.

---

Are you sure the PWD isn't issued before the put rather than after the chdir?  That's what it looked like in the code.

---

The PWD is issued directly before the put. This is to cache the current directory so that if the put fails, the auto-reconnect returns the user to the same location on the remote file system.

---

I rechecked my code, and I did have a directory listing in there that was causing the PWD after the login.  Removing the chDir did show that the PWD was coming from the PUT.  Using "client.put(new FileInputStream("a.a"),"a.a");" did result in the PWD command not being sent on the put, so it looks like we have a path forward.  Thanks so much for the help.

---

That's great.  By the way, if I were you I'd let the server admins know that, while rejecting a PWD command is perfectly reasonable, it's not reasonable to close the control channel in response.  There's a good chance that they don't even know that that's what happens.  Surely it wouldn't have been by design.