Технические препятствия для порта 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 Analytics привел меня сюда)

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

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

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

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

http://www.russiantequila.com/wiki/index.php ? название = Main_Page

Answer 3

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

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

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

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

Answer 4

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

Обсуждение Threads vs. Fork

Answer 5

Я был бы очень признателен за порт 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 получают ПЕРВЫЙ сигнал на сокете, чего не происходит в Unix.