Make methods virtual/implement strategy pattern

[Eleasar]

We have a (filezilla) server that emulates unix - directory names would not need to be escaped in this case (though it is marked as unix emulated). In the current form the code is very nicely encapsulated - but it is very hard to extend.

Maybe you could change the methods to virtual ones and private ones to protected. And/or include some strategy pattern to handle unix/windows specific logic (which could then be overridden or implemented as a new strategy for custom servers).

[picrap]

OK, I'm installing a FileZilla server to see all this. I'll let you know.

[picrap]

I took a look at FileZilla server, and news are not good.

• FileZilla server apparently does not support name escaping at all.
• There are two ways to make it work right now:
  • Implement the MLSD command (this is better anyway)
  • Use raw "CWD" / "LIST" (or possibly "STAT", I did not try) to get a directory listing. I create a ticket right now to implement MLSD command.

[Eleasar]

wow - thanks for your fast tests and response!

To be consistent you may want to change the "ProcessGetEntry" to use the "Stat" method (right now it misses the escaping).

Also it would help if the methods would be virtual so some custom adjustments can be implemented.

[picrap]

I committed a change with the EscapePath in ProcessGetEntry. A NuGet package (version 1.3) should be available in the next few minutes with this. I also added a FtpPlatform class where directory parsing and path escaping are processed. So this is not virtual as you expected, because I was too lazy to do this. However if you explain a little what you want to do exactly, I'd be happy to discuss it with you.

[Eleasar]

Will test it (soon) - thanks! Looks great.

As for virtual it was due to not being able to extend for some special behavior. I only tested now with filezilla which tells it is unix but in fact seems to support a few things from unix but for the rest depends on the underlying windows. So if there is another place to handle some special stuff it would be easy to inherit from FtpClient, handle some strange edge cases then in custom code. Or have some strategy patterns like the FtpPlatform one or callbacks in place to alter behavior for servers that do not behave correctly (maybe returning some unexpected status codes or such).

But this change solves already my issue so nothing too important for me.

[picrap]

FtpClient is actually a high-level wrapper for low-level commands (I found no other ftp client for doing both high-level and low-level commands, this is why I wrote this one), so you can easily implement your own commands as new methods (and inherited from FtpClient or FtpClientCore). I close this issue, but the MLST/MLSD stays open, of course. If you want, you can also fork the project, make your changes and submit them as a pull request.