Технические препятствия для порта Win32 rsync
Несмотря на то, что я в первую очередь пользователь Windows, я большой поклонник rsync. Теперь я не хочу спорить о достоинствах rsync по сравнению с любым другим инструментом ... это не моя точка зрения.
Единственный способ запустить rsync в Windows, который я когда-либо находил, - это использовать версию, созданную для работы поверх Cygwin, и, поскольку Cygwin имеет проблемы с Unicode, то же самое и с rsync.
Кто-нибудь достаточно знаком с работой rsync, чтобы сказать, есть ли какие-либо реальные проблемы технического программирования для переноса rsync на собственный двоичный файл Win32?
Или, может быть, пользователи Windows никогда не проявляли достаточного интереса, чтобы позаботиться о переносе?
Отчасти я спрашиваю, потому что я подумываю о том, чтобы попытаться взять на себя задачу запуска порта, но я хочу убедиться, что я не упускаю чего-то с точки зрения того, почему это может быть невозможно.
Ответы 5
Способ, которым Windows блокирует открытые файлы, может вызвать проблему, требующую подключения к службе теневого копирования тома.
Года два назад этот парень перенес алгоритм на C#. Я не изучал код (или предоставленный двоичный файл), но это может быть место, с которого можно начать поиск, или кто-то, кто попытается связаться с ним. http://www.russiantequila.com/wordpress/?p=8
Вы видели это:
http://www.itefix.no/i2/taxonomy/term/39
Я использовал cwrsync без каких-либо проблем (и с большей частью обычных страданий cygwin), но у меня не было необходимости в именах файлов Unicode, поэтому я не видел этой проблемы.
Я действительно не знаю, почему нет собственного порта Win32, но я некоторое время назад просмотрел исходный код, потому что реализовал аналогичную систему дельта-копирования на C#. Как и следовало ожидать от мира блестящих хакеров * nix, источником в основном являются односимвольные имена переменных и полное отсутствие комментариев, что не очень полезно и может оттолкнуть потенциальных носильщиков.
Я также оценивал усилия по переносу Win32. Я не верю, что что-то серьезное могло бы его заблокировать, но свидетельства как из список рассылки rsync, так и из другого обсуждения указывают на сильную зависимость от системных вызовов unix fork (). Использование потоков кажется подходящим вариантом для win32.
«Использование потоков - лучший способ для win32» - или порты завершения ввода-вывода, если вы хотите действительно хорошо масштабироваться ...
(отказ от ответственности: обещаю, я не гуглил сам, но Google Analytics привел меня сюда)
Я прошел через портирование rsync на .net (ссылка sig11 - это мой блог). здесь нет технических препятствий, только практические. как уже было сказано, код довольно ... плотный. сложно следить, и полное отсутствие комментариев. Я более чем счастлив сделать свою работу доступной, но, к сожалению, поскольку она была частью коммерческих усилий, она не в лучшем состоянии.
В ряде случаев у меня возникла путаница с идеей реверс-инжиниринга протокола и выполнения базовой реализации, совместимой с существующим протоколом, но ... немного более чистой для работы. Я даже начал вики по этому поводу, но ... как вы можете видеть по нехватке содержимого, другой элемент имеет приоритет. Если кто-то захочет поработать со мной над этим, это может быть стимулом, который мне нужен, чтобы начать работу.
концепция инструмента великолепна, как и предлагаемые им функциональные возможности, однако он довольно ограничен за пределами пространства * ix и определенно может извлечь выгоду из api.
Ссылка на вики для справки:
http://www.russiantequila.com/wiki/index.php?title=Main_Page
Колосы, я бы хотел получить копию того, что у тебя есть. Может, даже протяну руку, если смогу. Я согласен, более чистая версия с API была бы отличной, но, честно говоря, на данный момент моим первым приоритетом является версия для Windows, которая не полагается на Cygwin.
Однако я помогу, я хотел бы реализовать его на C / C++, и я также хотел бы создать версию кода LIB, чтобы мы могли разделить ее и использовать ее в собственном Win32 / GUI, а также в Windows сервис с графическим интерфейсом для настройки сервиса.
Я был бы очень признателен за перенос rsync на MS-Windows, чтобы его можно было создать с помощью Visual Studio. Я случайно и периодически сталкиваюсь с различными ошибками протокола. Я использую rsync для распределения sw в сетке из примерно 200 машин и обычно получаю около дюжины сбоев. Я использую GCC 4.4.2 и последнюю версию cygwin для сборки rsync v3.0.7. Мне бы очень помогло, если бы я мог поэкспериментировать с версией, не требующей cygwin. Это связано с тем, что на машинах в сетке уже запущено другое приложение на основе cygwin, версия которого отличается от того, что есть у меня.
Потратив некоторое время на список рассылки rsynv, мнения о причинах ошибок протокола в MS-Windows разделились. Некоторые говорят, что это ошибка в rsync, из-за которой не удалось полностью завершить работу сокета, ошибка, которая была исправлена некоторое время назад. Другие говорят, что это фундаментальная ошибка протокола в rsync, когда клиент не сообщает серверу, что он завершен, он просто выключается, в результате чего серверы MW-windows получают сигнал RST на сокете, чего не происходит в Unix. .
Быстрое обновление для ускорения работы тех, кто случайно просматривает страницы: автор, @kolosy, разместил исходный код на github в 2009 году, и с тех пор единственным действием были обновления до середины 2010 года Мэтью Стиплсом: github.com/MatthewSteeples/rsync.net