Obstacles techniques pour le port rsync Win32

Question

Bien que je sois principalement un utilisateur Windows, je suis un grand fan de rsync.Maintenant, je ne veux pas discuter des vertus de rsync par rapport à tout 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 conçue pour fonctionner sur Cygwin, et comme Cygwin a des problèmes avec Unicode, rsync aussi.

Quelqu'un est-il suffisamment familier avec le fonctionnement de rsync pour dire s'il existe de réels obstacles techniques en matière de programmation pour porter rsync vers un binaire Win32 natif ?

Ou est-ce peut-être parce que les utilisateurs de Windows n’ont jamais suscité suffisamment d’intérêt pour le porter ?

Je pose cette question en partie parce que j'envisage d'essayer de démarrer un portage, mais je veux m'assurer qu'il n'y a rien qui me manque quant à la raison pour laquelle cela pourrait ne pas être possible.

Answer 1

La façon dont Windows verrouille les fichiers ouverts peut entraîner un problème vous obligeant à vous connecter au service Volume Shadowcopy.

Il y a environ deux ans, cet homme a porté l'algorithme en C#.Je n'ai pas jeté un œil au code (ou au binaire fourni), mais cela pourrait être un point de départ pour commencer à chercher ou quelqu'un à contacter.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

(clause de non-responsabilité:je le promets, je ne cherche pas sur Google moi-même, mais Google Analytics m'a amené ici)

j'ai porté rsync sur .net (le lien de sig11 est mon blog).il n’y a pas d’obstacles techniques, juste des obstacles pratiques.comme cela a déjà été dit, le code est plutôt...dense.difficile à suivre et absence totale de commentaires.Je suis plus qu'heureux de rendre mon travail disponible, mais malheureusement, comme il faisait partie d'un effort commercial, il n'est pas en bien meilleur état.

J'ai, à plusieurs reprises, joué avec l'idée de procéder à une ingénierie inverse du protocole et de réaliser une implémentation de base compatible avec celle existante, mais...un peu plus propre à travailler.j'ai même commencé un wiki à cet effet, mais...comme vous pouvez le voir d'après le manque de contenu, d'autres éléments ont eu la priorité.si quelqu'un souhaite travailler avec moi là-dessus, c'est peut-être l'impulsion dont j'ai besoin pour commencer.

le concept de l'outil est génial, tout comme les fonctionnalités qu'il offre, cependant 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 3

Avez-vous vu cette:

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

J'ai utilisé cwrsync sans aucun problème (et avec la grande misère habituelle de Cygwin), mais je n'ai pas eu besoin de noms de fichiers Unicode, 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 il y a quelque temps car 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 constituée de noms de variables à un seul caractère et d'une absence totale de commentaires, ce qui n'est pas très utile et pourrait être plutôt rebutant pour les porteurs potentiels.

Answer 4

J'ai également évalué un effort pour entreprendre un portage win32.Je ne pense pas que quelque chose d'important puisse le bloquer, mais les preuves provenant à la fois du liste de diffusion rsync et une autre discussion souligne une forte dépendance aux appels système Unix fork().L'utilisation de threads semble être la voie à suivre pour win32.

Fils contre.Discussion à la fourchette

Answer 5

J'apprécierais vraiment un portage de rsync vers MS-Windows tel qu'il puisse être construit à l'aide de Visual Studio.Je rencontre diverses erreurs de protocole au hasard, de manière quelque peu intermittente.J'utilise rsync pour distribuer sw sur une grille d'environ 200 machines et contourner généralement une douzaine d'échecs.J'utilise GCC 4.4.2 et le dernier cygwin pour créer rsync v3.0.7.Cela m'aiderait beaucoup si je pouvais expérimenter une version qui ne nécessite pas Cygwin.En effet, les machines de la grille disposent déjà d'une autre application basée sur Cygwin, dont la version est différente de celle que j'ai.

Après avoir passé du temps sur la liste de diffusion rsynv, les avis semblent partagés quant à la cause des erreurs de protocole sous MS-Windows.Certains disent qu'il s'agit d'un bug dans rsync où il n'a pas réussi à effectuer un arrêt propre du socket, un bug qui a été corrigé il y a quelque temps.D'autres disent qu'il s'agit d'une erreur de protocole fondamentale dans rsync où le client ne dit pas au serveur que c'est terminé, il s'arrête simplement, ce qui amène les serveurs MW-Windows à recevoir un signal RST sur le socket, ce qui n'arrive pas sous Unix. .