Commands don't respect code-property in thrown errors

[lovenm]

The errors defined in errors.js all contain the code-property, and what looks like a FTP error code gets assigned there when something throws/rejects, so I presumed I could control what code is replied with that when something is thrown in my custom file system.

Seems that at least some, if not all, commands don't respect the error codes contained in thrown errors, and instead substitute a preset error code for errors that gets thrown/rejected during that command. For example:
https://github.com/trs/ftp-srv/blob/eca26ee86a6c9a273d66f9f14117db7be8eb6831/src/commands/registration/retr.js#L52-L56

Is this by design? Fixing this seems quite simple, so I could maybe do a PR of this if it's not by design.

[trs]

Normally the ftp client is expecting a certain error code back. It's not as open ended as say an HTTP error response.

What's your use case for this?

[lovenm]

I have a custom file system. I get a RETR command for a file that the file system determines does not exist. I'd like to return 550 to indicate that the file is not available, yet with the current functionality it will always return 551 which has a completely different meaning (and looks like it isnt even a valid reply for RETR).

At least according to the FTP specification, 550 is a valid reply for RETR commands.

RETR
  125, 150
    (110)
    226, 250
    425, 426, 451
  450, 550
  500, 501, 421, 530

[trs]

That should be 550 and not 551 anyway, thanks.

We can explore allowing the reply code to be set using errors, and falling back to a default if not set?

this.reply(err.code || 550, err.message);

This would allow more specific error codes from the file system.

[lovenm]

Yes, that was my idea for the fix to this as well.