Native Windows port

[segevfiner]

With OpenSSH now having a native Windows port that is included by default, it would be cool to also have rsync, but this would require porting rsync to Windows with a compatibility layer like was done for OpenSSH. And it is possible the maintainers of rsync hate Windows so will simply reject any attempt to do so, so it might end up being a fork that someone will have to maintain if it is ever done.

[mitchcapper]

Rsync with cygwin/msys2 has been around for quite some time. In terms of a more native port it seems not a huge mountain from a cursory look, although that is only the task of getting it compiling:

I do native builds with MSVC for many gnu/nix tools avoiding emulation layers / mingw ( https://github.com/mitchcapper/WIN64LinuxBuild ). Given the ticket I figured I would give rsync a look. Most of the gnulib polyfill works. The biggest thing left are the forks which are admittedly some of the more annoying code to port on these things.

In all I count 8 fork calls that would need porting some more complex than others:

• 2x clientserver.c
• 2x main.c
• 2x pipe.c
• 2x socket.c

none of those are big util calls (aka lots of other code calling into those forks so much as more contained fork logic flows).

Doing the fork ports though is fairly specific to each usage though as the gnulib best helpers still require the flow to be a good bit different from a simple fork(). I have done such ports for tar and findutils for example:
mitchcapper/findutils@master...win32_enhancements
mitchcapper/tar@master...win32_enhancements (most of tars are in that system.c).

Without a doubt even once those are re-written and it compiles there will be some other issues but I don't think there is anything overly fundamentally divergent in the rsync code that would prevent the port from working with some dev hours into it.

If you have interest on working on these things let me know I can put up what I have so far.