Технические препятствия для порта Win32 rsync

Question

Несмотря на то, что я в основном пользователь Windows, я большой поклонник rsync. Теперь я не хочу спорить о достоинствах rsync по сравнению с любым другим инструментом ... это не моя точка зрения.

Единственный способ запустить rsync в Windows - это версия, созданная для запуска поверх Cygwin, и, поскольку у Cygwin есть проблемы с Unicode, то же самое касается rsync.

Кто-нибудь достаточно знаком с работой rsync, чтобы сказать, существуют ли какие-либо реальные технические препятствия для программирования при переносе rsync на собственный двоичный файл Win32?

Или, может быть, у пользователей Windows никогда не было достаточно интереса, чтобы портировать его?

Отчасти я спрашиваю, потому что я рассматриваю попытку взять на себя задачу запуска порта, но я хочу убедиться, что мне не хватает чего-то в плане того, почему это невозможно.

Answer 1

То, как Windows блокирует открытые файлы, может вызвать проблему, требующую подключения к службе Volume Shadowcopy.

Около двух лет назад этот парень перенес алгоритм на C #. Я не взглянул на код (или предоставленный двоичный файл), но это может быть место, где можно начать поиск, или кто-то, кто попытается связаться.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

(отказ от ответственности: я обещаю, я не Google, но Google Analytics привел меня сюда)

я прошел портирование rsync на .net (ссылка на sig11 - мой блог). нет никаких технических препятствий, только практические. Как уже было сказано, код довольно ... плотный. трудно следовать, и полное отсутствие комментариев. Я более чем счастлив сделать мою работу доступной, но, к сожалению, поскольку она была частью коммерческой деятельности, она не в значительно лучшей форме.

В ряде случаев я возился с идеей обратного инжиниринга протокола и создания базовой реализации, совместимой по проводам с существующей, но ... немного более чистой для работы. Я даже начал вики с этой целью, но ... как вы можете видеть по отсутствию содержимого, другие предметы имеют приоритет. если кто-то хотел бы поработать со мной над этим, это может быть стимулом, который мне нужен для начала.

Концепция инструмента великолепна, как и функциональность, которую он предлагает, однако он довольно ограничен вне пространства * ix и может определенно выиграть от API.

ссылка на вики для справки:

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

Answer 3

Мне бы очень хотелось, чтобы порт 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 .

Answer 4

Я также оценивал усилия по созданию порта win32. Я не верю, что что-то серьезное заблокировало бы это, но доказательства из списка рассылки rsync и другого обсуждения указывают на сильную зависимость от системных вызовов unix fork (). Использование потоков - это путь к win32.

Обсуждение темы против Форка

Answer 5

Вы видели это:

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

Я использовал cwrsync без каких-либо проблем (и с большинством обычных страданий cygwin), но у меня не было необходимости в именах файлов в Юникоде, поэтому я не видел этой проблемы.

Я действительно не знаю, почему нет собственного порта Win32, но некоторое время назад я посмотрел на исходный код, потому что реализовал аналогичную систему дельта-копирования в C #. Как и следовало ожидать от мира блестящих * nix-хакеров, источник в основном состоит из односимвольных имен переменных и полного отсутствия комментариев, что не очень полезно и может быть довольно неприятным для потенциальных носильщиков.