Technical obstacles for the Win32 rsync port

Question

Although I am primarily a Windows user, I am a huge fan of rsync. Now I do not want to argue about the merits of rsync and any other tool ... this is not my point.

The only way I've ever encountered running rsync for Windows is with a version that is built to run on top of Cygwin, and since Cygwin has problems with Unicode, rsync also.

Is anyone familiar enough with rsync's work to say if there are any real barriers to programming for porting rsync to a native Win32 binary?

Or could it be that window users never had enough interest to take care of porting it?

Partly I ask because I am thinking about trying to start working with the port, but I want to make sure that something is missing, in terms of why this might not be possible.

Answer 1

The way to block Windows files that are being opened can cause a problem that requires you to connect to the Volume Shadowcopy service.

About two years ago, this person ported the algorithm to C #. I did not look at the code (or the provided binary), but it could be a place to search or someone to contact.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

(disclaimer: I promise, I'm not Google myself, but Google Analytics brought me here)

I went through porting rsync to .net (sig11 link is my blog). There are no technical obstacles, just practical. as already mentioned, the code is pretty ... tight. hard to follow, and complete lack of comment. I am more than happy to make my work available, but unfortunately, since it was part of a commercial effort, it is not in much better shape.

In some cases, I came up with the idea of ​​reverse-engineering the protocol and carried out an innovative implementation related to wired compatibility with the existing one, but ... a little clean for work. I even started a wiki with this effect, but ... as you can see due to the lack of content there, another element takes precedence. if someone wants to work with me about this, this may be the incentive that I need to achieve.

the concept of the tool is great, as is the functionality that it offers, however it is rather limited outside the ix space and can definitely benefit from the api.

Wiki link for reference:

http://www.russiantequila.com/wiki/index.php?title=Main_Page

Answer 3

Did you see that:

http://www.itefix.no/i2/taxonomy/term/39

I used cwrsync without any problems (and with most of the usual cygwin trouble), but I do not need the file names in unicode, so I did not see this problem.

I don’t know why there is no Win32 native port, but I looked at the source a while ago because I implemented a similar delta copy system in C #. As you would expect from the world of ingenious nix hackers, the source is mainly single-character variable names and a complete lack of comments, which is not terribly useful and can be rather removed from potential carriers.

Answer 4

I also appreciated the effort to create a win32 port. I do not believe that something big would block it, but the data from both the rsync mailing list and another discussion indicate a lot of dependence on unix fork () system calls. Using threads is the way to win32.

Topics versus discussion in a fork

Answer 5

I would really like the rsync port for MS-Windows so that it can be created using Visual Studio. I encounter various protocol errors in random order, somewhat intermittently. I use rsync to distribute sw to a grid of about 200 machines and usually dozens of crashes. I am using GCC 4.4.2 and the latest cygwin to build rsync v3.0.7. This would help me a lot if I could experiment with a version that does not require cygwin. This is because the machines in the grid already have another cygwin based application that is different from the one I have.

After spending some time on the rsynv mailing list, it looks like it is split into the cause of protocol errors in MS-Windows. Some say this is an error in rsync where it was not possible to perform a clean socket close, an error that was fixed some time ago. Others say that this is a fundamental protocol error in rsync, where the client does not tell the server that it is completed, it simply shuts down, causing the MW-windows servers to receive an RST signal on the socket, which does not happen on Unix.