Ask a Question

Server not returning SSH_FXP_STATUS response

0 votes
by (150 points)
edited by

Hi,

We are having an issue with a particular Client's server where we seem to enter into an infinite loop with the server never responding with SSHFXPSTATUS response. The only real clue I have is that just before it enters into what appears to be an infinite loop the logs report a "Duplicate item encountered".

This feels like an issue with the server as it's not giving the correct response but I wondered if there was any known reason why this might happen? I can see earlier in the day in the logs a "Duplicate item encountered" response is given but immediately afterwards the SSHFXPSTATUS response is given and the operation completes so I'm not sure that is the cause.

Example from the logs below with file names etc altered for privacy:

2023-01-16 14:32:09.851 DEBUG Sftp(7029)[5] Info: Item: -rw-rw-rw-   1 0        0            8489 Jan 16 04:27 AFiles.XLSX
2023-01-16 14:32:09.852 DEBUG Sftp(7029)[5] Info: Item: -rw-rw-rw-   1 0        0            3787 Jan 16 04:27 AnotherFile.XLSX
2023-01-16 14:32:09.852 DEBUG Sftp(7029)[5] Info: Item: -rw-rw-rw-   1 0        0            8664 Jan 16 04:28 OneMoreFileFile.XLSX
2023-01-16 14:32:09.852 DEBUG Sftp(7029)[5] Info: Item: -rw-rw-rw-   1 0        0           58558 Jan 16 04:28 DuplicateFile.XLSX
2023-01-16 14:32:09.852 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (82, 0x2D313737333435313934352D343837303135323239)
2023-01-16 14:32:09.970 INFO Sftp(7029)[5] Response: SSH_FXP_NAME (82, 1 item)
2023-01-16 14:32:09.970 DEBUG Sftp(7029)[5] Info: Item: -rw-rw-rw-   1 0        0           58558 Jan 16 04:28 DuplicateFile.XLSX
2023-01-16 14:32:09.970 INFO Sftp(7029)[5] Info: Duplicate item encountered: '/Directory/SubDirectory/DuplicateFile.XLSX'.
2023-01-16 14:32:09.970 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (83, 0x2D313737333435313934352D343837303135323239)
2023-01-16 14:32:10.066 INFO Sftp(7029)[5] Response: SSH_FXP_NAME (83, 0 items)
2023-01-16 14:32:10.066 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (84, 0x2D313737333435313934352D343837303135323239)
2023-01-16 14:32:10.164 INFO Sftp(7029)[5] Response: SSH_FXP_NAME (84, 0 items)
2023-01-16 14:32:10.164 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (85, 0x2D313737333435313934352D343837303135323239)
2023-01-16 14:32:10.261 INFO Sftp(7029)[5] Response: SSH_FXP_NAME (85, 0 items)
2023-01-16 14:32:10.261 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (86, 0x2D313737333435313934352D343837303135323239)
2023-01-16 14:32:10.363 INFO Sftp(7029)[5] Response: SSH_FXP_NAME (86, 0 items)
2023-01-16 14:32:10.363 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (87, 0x2D313737333435313934352D343837303135323239)
2023-01-16 14:32:10.465 INFO Sftp(7029)[5] Response: SSH_FXP_NAME (87, 0 items)
2023-01-16 14:32:10.466 INFO Sftp(7029)[5] Command: SSH_FXP_READDIR (88, 0x2D313737333435313934352D343837303135323239

Carries on for hours until the Windows Service responsible is re-started
Applies to: Rebex SFTP

1 Answer

+1 vote
by (148k points)

This is apparently a server-side bug (a serious SFTP protocol violation). The proper solution is to report it to the server vendor to have it fixed.

If they are uncooperative, you might be able to work around the issue by registering ListItemReceived event on Sftp object, and calling Abort() on SftpListItemReceivedEventArgs when the duplicate item is detected.

...