IOException instead of SftpPathNotFoundException with SFTPgo and S3 backend

[msitms]

I know this sounds like a server problem at first, but all other clients I tried so far work just fine.

Scenario: GET (in SSH.NET, SftpClient.OpenRead) a file that doesn't exist on the server.

Usual behavior with other servers: OpenRead throws a SftpPathNotFoundException exception.

Actual behavior: OpenRead throws no exception, but when trying to read from the stream, a generic IOException is thrown:

System.IO.IOException: Seek operation failed.
   at Renci.SshNet.Sftp.SftpFileStream.get_Length()
   at System.IO.Stream.GetCopyBufferSize()
   at System.IO.Stream.CopyTo(Stream destination)

I'm using SSH.NET 2024.2.0 with SFTPGo 2.6.6 here. The described behavior only occurs when I'm using a SFTPgo user with S3 storage. When connecting with a user configured for local storage, it works as expected.

Now I know that this sounds like a SFTPGo error at first, and the behavior for the two storage backends is indeed different, but it seems like it still conform to the standard. The server logs indicate that a SSH_FXP_STATUS with status code 2 is sent in both cases. Also, I tried to do the same in Python using the paramiko package, and it gives me [Errno 2] no such file in both cases. However, with local storage, I get this exception right when opening the file, and with S3 storage, only when trying to read from the stream.

I cannot replicate the behavior with the sftp command. Its verbose output indicates that it always sends a SSH_FXP_STAT command before trying to actually get the file, so I don't run into the same situation:

sftp> get foobar
debug1: stat remote: No such file or directory
File "/foobar" not found.

I also captured the traffic, trying to find out what is actually going on on the wire, but Wireshark cannot dissect SSH packages.

If you like to reproduce the problem, the easiest way should be to run a local Docker container (image: drakkan/sftpgo:alpine-slim), and set up the a user with S3 storage:
https://docs.sftpgo.com/2.6/docker/#supported-tags-and-respective-dockerfile-links
https://docs.sftpgo.com/2.6/s3/

If you have any idea how I could capture the raw traffic in a way that is readable for you, please let me know. If necessary, I could also set up a temporary cloud-based instance for testing.

It would be perfectly fine if the exception is thrown only when trying to read from the stream, but it should be the SftpPathNotFoundException exception, not some generic exception that could also be caused by e.g. a network hiccup.