Techniques haies pour Win32 rsync port

Question

En dépit d'être principalement un utilisateur de Windows, je suis un grand fan de rsync. Maintenant, je ne veux pas discuter des vertus de rsync par rapport à n'importe quel autre outil ... ce n'est pas mon propos. La seule façon que j'ai jamais trouvée d'exécuter rsync sur Windows est via une version qui est construite pour fonctionner sur Cygwin, et comme Cygwin a des problèmes avec Unicode, rsync aussi.

Quelqu'un connaît-il assez bien le fonctionnement de rsync pour dire s'il y a de véritables obstacles techniques à la portabilité de rsync vers un binaire Win32 natif?

Ou est-ce peut-être qu'il n'y a jamais eu assez d'intérêt de la part des utilisateurs de Windows pour se soucier de le transférer?

En partie, je demande parce que je suis en train d'envisager d'essayer de démarrer un port, mais je veux m'assurer qu'il n'y a pas quelque chose qui me manque pour expliquer pourquoi ce n'est pas possible.

Answer 1

La façon dont Windows verrouille l'ouverture des fichiers peut entraîner un problème nécessitant votre connexion au service Volume Shadowcopy.

Il ya environ deux ans, ce type a porté l'algorithme en C#. Je n'ai pas regardé le code (ou le binaire fourni), mais c'est peut-être un endroit où commencer à chercher ou quelqu'un à essayer de contacter.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

Avez-vous vu ceci:

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

J'ai utilisé cwRsync sans aucun problème (et avec la grande partie de la misère habituelle Cygwin), mais je n'ai pas eu besoin d'unicode noms de fichiers, donc je n'ai pas vu ce problème. Je ne sais pas vraiment pourquoi il n'y a pas de port Win32 natif, mais j'ai regardé la source tout à l'heure parce que j'ai implémenté un système de copie delta similaire en C#. Comme on peut s'y attendre du monde des brillants hackers * nix, la source est en grande partie des noms de variables à caractère unique et une absence totale de commentaires, ce qui n'est pas terriblement utile et pourrait être plutôt rebutant pour les porteurs potentiels.

Answer 3

J'ai également évalué un effort pour entreprendre un port win32. Je ne crois pas que quelque chose de majeur le bloquerait, mais les preuves à la fois du rsync mailing list et d'une autre discussion indiquent une forte dépendance aux appels système unix fork(). L'utilisation de threads semble être le bon choix pour win32.

Threads vs. Fork discussion

Answer 4

(disclaimer: je promets, je ne me google pas, mais Google Analytics m'a amené ici)

Je suis passé par le portage rsync vers .NET (lien de Sig11 est mon blog). il n'y a pas d'obstacles techniques, seulement pratiques. comme on l'a déjà dit, le code est plutôt ... dense. difficile à suivre, et un manque total de commentaires. Je suis plus qu'heureux de rendre mon travail disponible, mais malheureusement, comme cela faisait partie d'un effort commercial, il n'est pas en très bonne forme. J'ai eu l'occasion, à plusieurs reprises, d'inverser le protocole et de mettre en place une implémentation qui soit compatible avec l'existant, mais ... un peu plus propre à travailler avec . J'ai même commencé un wiki à cet effet, mais ... comme vous pouvez le voir à cause du manque de contenu, d'autres éléments ont pris la priorité. Si quelqu'un veut travailler avec moi à ce sujet, c'est peut-être l'impulsion dont j'ai besoin pour aller de l'avant.

le concept de l'outil est génial, tout comme la fonctionnalité qu'il offre, mais il est plutôt limité en dehors de l'espace * ix, et pourrait certainement bénéficier d'une api.

lien wiki pour référence:

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

Answer 5

J'apprécierais vraiment un port de rsync à MS Windows de telle sorte qu'il peut être construit en utilisant Visual Studio. Je rencontre plusieurs erreurs de protocole au hasard, de façon intermittente. J'utilise rsync pour distribuer sw sur une grille d'environ 200 machines et en règle générale une douzaine d'échecs. J'utilise GCC 4.4.2 et le dernier cygwin pour construire rsync v3.0.7. Cela m'aiderait beaucoup si je pouvais expérimenter avec une version qui ne nécessite pas cygwin. En effet, les machines de la grille ont déjà une autre application cygwin en cours d'exécution qui est une version différente de celle que j'ai. Ayant passé du temps sur l'avis de liste de diffusion rsynv semble être divisé quant à la cause des erreurs de protocole sur MS-Windows. Certains disent que c'est un bug dans rsync où il a échoué à faire une fermeture de socket propre, un bug qui a été corrigé il y a un moment. D'autres disent qu'il s'agit d'une erreur de protocole fondamentale dans rsync où le client ne dit pas au serveur qu'il est terminé, il s'arrête juste, provoquant un signal RST sur le socket des serveurs MW-windows, ce qui n'arrive pas sous Unix .