Enhancing portability and error handling in wolfSSH

[falemagn]

Hi,

While integrating wolfSSH within FileZilla Professional Enterprise Server, which exposes its own filesystem abstraction, I found the need to modify some functions in wolfsftp.c. Specifically, I aimed to return to the client a more meaningful error status than WOLFSSH_FTP_FAILURE, where appropriate.

To achieve this without substantial refactoring, I've added new WS_ErrorCodes enums, which are then mapped onto the appropriate WS_SFTPStatus enums, alongside the existing WS_ErrorCodes.

However, I acknowledge that this solution is suboptimal for a couple of reasons. First, it requires extending WS_ErrorCodes with values that are exclusively used for translation into SFTP-specific ones. Second, the existing WS_ErrorCodes don't always match with the WS_SFTPStatus enums.

As noted in some of the comments in wolfsftp.c, it would be more effective to directly translate the specific underlying framework error tied to the failed operation onto the corresponding WS_SFTPStatus (and error message). But such an implementation would involve significantly more changes to the codebase, impacting parts I can't test directly due to lack of access to all platforms where wolfSSH is being used.

Thus, I've implemented changes that are specific to the FileZilla Server integration, and while they address the immediate need, I don't believe the patch is in a state that can be readily merged into the upstream. A more coordinated effort seems necessary to make wolfSSH more platform agnostic. This could involve less dependence on macros and structuring a more defined middleware API.

With this issue, I aim to open a discussion on these possibilities. If such changes are welcome, we can then agree on a roadmap moving forward.

[ejohnstown]

I have started a branch where I am converting the file system function macro wrappers into functions of their own. I'm starting with your PR #556 and making sure everything is covered. The branch is in my repo at https://github.com/ejohnstown/wolfssh/tree/wolf-file
Is this similar to what you are talking about? (The error codes are definitely another issue.)