`SFTP::put()` fails silently with no provided error information if path does not exist

[dmjohnsson23]

`SFTP::put()` fails silently with no provided error information if path does not exist

[terrafrost]

Try getLastSFTPError().

When I try to upload a file to a directory that doesn't exist the server responds, on the SFTP layer, with an SSH_FXP_STATUS message with an error/status code of SSH_FX_NO_SUCH_FILE and an error message of "No such file".

Ultimately, however, phpseclib is just reporting on what the server is saying. If the server is silently failing there isn't a whole lot that phpseclib can do to glean information about that.

But, in this case, I suspect the server isn't silently failing and that you're just calling the wrong method.

[dmjohnsson23]

I do find it somewhat confusing that the getLastError and getLastSFTPError are separate methods, but it does appear I was just using the wrong method.

[terrafrost]

I do find it somewhat confusing that the getLastError and getLastSFTPError are separate methods

It might be something to consider changing for phpseclib 4.0+ as backwards compatibility won't be an issue in that version.

As for why it has the design that it currently does... so SFTP operates at a layer above the SSH layer. So in SSH you have SSH_MSG_CHANNEL_DATA packets, among other packet types. SFTP packets are contained within SSH_MSG_CHANNEL_DATA packets. An SFTP packet may span multiple SSH_MSG_CHANNEL_DATA packets or there could be multiple SFTP packets in one SSH_MSG_CHANNEL_DATA, it all depends.

Because one is embedded in the other it makes sense to have separate logs. So like if you have the SSH logs you can extract the SFTP logs since SFTP packets are embedded within SSH packets but you can't get SSH packets from SFTP packets.

getLastError and getLastSFTPError are split for those same reasons. If the server sends an SSH_MSG_DEBUG packet to the client that's logged in getLastError. Even if SSH_MSG_DEBUG doesn't contain an error, per say, it none-the-less, ends up in getLastError. Likewise, if the server sends a SSH_MSG_GLOBAL_REQUEST packet to the client phpseclib will reject it and log the request name in getLastError. If the server sends an exit-signal SSH_MSG_CHANNEL_REQUEST then the signal name is logged in getLastError and, if the packet contains, the error message.

Basically, it reports on debug info reported on by the server. So like if phpseclib can't read a RSA private key that's not gonna be in getLastError - that'll throw an exception. phpseclib doesn't throw an exception if getLastError is updated because, honestly, it might not rise to the level of an exception anyway.

Similarly, getLastSFTPError returns information returned by the SFTP layer. So SFTP packets are prefixed in the SFTP specs by SSH_FXP_*. So consider get(). phpseclib sends 32x SSH_FXP_READ packets (all contained within SSH_MSG_CHANNEL_DATA packets) for successive parts of a file and should get back 32 or less SSH_FXP_DATA packets (this is done for speed and is also done by PuTTY / WinSCP / etc). If it gets less then 32 SSH_FXP_DATA packets then it should get 32 SSH_FXP_STATUS packets back less the number of SSH_FXP_DATA packets that it got back. If it receives an SFTP packet that isn't either of those an exception is thrown.

An SSH_FXP_STATUS packet contains a 32-bit integer value representing the error/status code and a string representing the error message. So unless the file being read is exactly a multiple of 1MB (32KB*32) then you'll get a bunch of absolutely non-fatal message about how the requested file offset is invalid because it's larger then the size of the file or some such.

Should SFTP / SSH "messages" be grouped together? Maybe. But the fact that they're not can also give you clues as to where the error is specifically happening. I mean, I suppose I could preface SFTP layer messages with SFTP: and SSH layer messages with SSH2: and then you could look at the string to determine what's what.

I mean, I'm not opposed to changing it for a new version of phpseclib but, anyway, the above is why they (currently) exist as two separate methods. TLDR it's because it mirrors how SFTP operates at a different layer than SSH does.

[dmjohnsson23]

Thank you for the detailed explanation. It does shed some light onto why it is that way.

Could I suggest a few additions to the documentation to help make the distinction more clear?

For getLastError, I would suggest the following docstring:

Returns the last error received on the SSH layer.

If you are looking for messages from the SFTP layer, please instead see getLastSFPTError.

For getLastSFTPError, I think the name already helps make the distinction clear, but it could be helpful to change it to:

Returns the last error received on the SFTP layer.

For me at least, when I was reading the documentation for the proper way to get error information, I came across getLastError and (incorrectly) assumed from the name and description that was pretty clearly and obviously the method I needed, and therefore didn't continue looking to find getLastSFTPError. Having something to signal the more limited scope of the method would have prompted me to keep looking.

[terrafrost]

See a69364d