Fallbacks for servers that do not support `fsync`?

[m90]

I am using this package in a backup tool that uploads and deletes archives from remote servers. An issue was raised that deletion fails SSH_FX_FAILURE in cases the server does not support fsync.

Is there any way built into this package that would let me fall back to plain ssh commands or something similar in such cases, or would clients need to do this in a completely separated track?

[puellanivis]

Huh… it does seem we’re not checking to ensure the fsync permission is available before sending it… but I also don’t think the fsync is related to the issue seen in the issue linked…

There’s really not a fall back that could be done for servers that don’t support fsync, we would just need to short-circuit return nil in such a case.

In any case, let’s continue to convo there. (I’m just dropping this here for anyone stumbling on this issue first.)

[puellanivis]

dev-2 already has a short-circuit to return an sshfx.StatusOpUnsupported if the extension is not supported. Clients will still need to anticipate that this error might happen, and ignore such an error if it happens, but there isn’t the possibility that we should send a packet that we know the server will reject, which can at times cause the server to disconnect. (Though, I don’t see why it would need to, just sending back an SSH_FX_OP_UNSUPPORTED and then carrying on should be fine. 🤔 Anyways, better to not send a packet that the server says it would reject anyways.)

Would you like to make a ticket to add checking the extension to exist in the v1 API, or shall I?

[m90]

I'm under the impression you're finding your way around this topic a lot better than I do, so if you could do it, that'd create a much more informative and precise issue I guess. Thanks.

[puellanivis]

Resolved by #618