winapi - ejemplos - Obstáculos técnicos para el puerto rsync de Win32
rsync ejemplos (5)
A pesar de ser principalmente un usuario de Windows, soy un gran fanático de rsync. Ahora, no quiero discutir las virtudes de rsync frente a cualquier otra herramienta ... este no es mi punto.
La única forma que he encontrado de ejecutar rsync en Windows es a través de una versión que está diseñada para ejecutarse sobre Cygwin, y como Cygwin tiene problemas con Unicode, también lo hace rsync.
¿Alguien está lo suficientemente familiarizado con el funcionamiento de rsync para decir si hay algún obstáculo de programación técnico real para portar rsync a un binario Win32 nativo?
¿O es tal vez que nunca ha habido suficiente interés por parte de los usuarios de Windows como para importarle el puerto?
En parte, pregunto porque estoy considerando intentar asumir la tarea de iniciar un puerto, pero quiero asegurarme de que no me falte algo en términos de por qué no es posible.
Has visto esto:
http://www.itefix.no/i2/taxonomy/term/39
He usado cwrsync sin ningún problema (y con la mayor parte del sufrimiento habitual de cygwin), pero no he tenido necesidad de nombres de archivos unicode, así que no he visto ese problema.
Realmente no sé por qué no hay un puerto Win32 nativo, pero miré la fuente hace un tiempo porque implementé un sistema delta-copy similar en C #. Como es de esperar del mundo de los hackers brillantes * nix, la fuente son en gran parte nombres de variables de un solo carácter y una ausencia total de comentarios, lo que no es de gran ayuda y podría ser algo desagradable para los aspirantes a porteros.
La forma en que Windows bloquea los archivos puede causar un problema que le obligue a engancharse en el Servicio de Volume Shadowcopy.
Hace aproximadamente dos años este compañero portó el algoritmo a C #. No he echado un vistazo al código (o al binario proporcionado), pero podría ser un lugar para comenzar a buscar o alguien para intentar contactar.
http://www.russiantequila.com/wordpress/?p=8
He estado evaluando un esfuerzo para llevar a cabo un puerto win32 también. No creo que nada importante lo bloquee, pero la evidencia de la lista de correo rsync y otra discusión apuntan a una gran dependencia de las llamadas al sistema unix fork (). Usar hilos parece ser el camino a seguir para win32.
(descargo de responsabilidad: lo prometo, no busco en Google, pero google analytics me trajo aquí)
Pasé portando rsync a .net (el enlace de sig11 es mi blog). no hay obstáculos técnicos, solo prácticos. como ya se dijo, el código es bastante ... denso. difícil de seguir y completa falta de comentarios. Estoy más que feliz de poder hacer que mi trabajo esté disponible, pero desafortunadamente, como era parte de un esfuerzo comercial, no está en una mejor forma.
En varias ocasiones, me he equivocado con la idea de aplicar ingeniería inversa al protocolo y hacer una implementación básica compatible con el cable existente, pero ... un poco más limpio para trabajar. Incluso he comenzado una wiki para ese efecto, pero ... como se puede ver por la falta de contenido allí, otros elementos han tenido prioridad. si alguien quisiera trabajar conmigo en esto, ese puede ser el ímpetu que necesito para irme.
el concepto de la herramienta es genial, como lo es la funcionalidad que ofrece, sin embargo, es bastante limitado fuera del espacio * ix, y definitivamente podría beneficiarse de una API.
enlace wiki para referencia:
http://www.russiantequila.com/wiki/index.php?title=Main_Page
Realmente agradecería un puerto de rsync para MS-Windows para que pueda ser construido usando Visual Studio. Me encuentro con varios errores de protocolo al azar, de forma intermitente. Estoy usando rsync para distribuir sw a una grilla de alrededor de 200 máquinas y normalmente puedo resolver una docena de fallas. Estoy usando GCC 4.4.2 y el último cygwin para compilar rsync v3.0.7. Me ayudaría mucho si pudiera experimentar con una versión que no requiere cygwin. Esto se debe a que las máquinas en la red ya tienen otra aplicación basada en cygwin en ejecución, que es una versión diferente a la que tengo.
Después de haber pasado algún tiempo en la lista de correo rsynv la opinión parece estar dividida en cuanto a la causa de los errores de protocolo en MS-Windows. Algunos dicen que es un error en rsync en el que no se pudo cerrar el socket, un error que se solucionó hace un tiempo. Otros dicen que es un error de protocolo fundamental en rsync donde el cliente no le dice al servidor que ha terminado, simplemente se apaga, lo que hace que los servidores MW-windows obtengan una señal RST en el socket, algo que no ocurre en Unix. .