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

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

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

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

Обсуждение тем и вилок

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

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

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

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

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

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

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

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

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

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

Я был бы очень признателен за порт rsync для MS-Windows, чтобы его можно было построить с помощью Visual Studio. Я сталкиваюсь с различными ошибками протокола случайным образом, иногда с перерывами. Я использую rsync для распределения программного обеспечения по сетке из примерно 200 машин и обычно получаю около дюжины сбоев. Я использую GCC 4.4.2 и последнюю версию cygwin для сборки rsync v3.0.7. Мне бы очень помогло, если бы я мог поэкспериментировать с версией, которая не требует cygwin. Это связано с тем, что на машинах в сетке уже запущено другое приложение на основе cygwin, версия которого отличается от той, что у меня есть.

Потратив некоторое время на список рассылки rsynv, мнения, похоже, разделились относительно причин ошибок протокола в MS-Windows. Некоторые говорят, что это ошибка в rsync, из-за которой не удалось выполнить чистое отключение сокета, ошибка, которая была исправлена ​​некоторое время назад. Другие говорят, что это фундаментальная ошибка протокола в rsync, когда клиент не сообщает серверу о завершении, он просто отключается, в результате чего серверы MW-Windows получают сигнал RST на сокете, чего не происходит в Unix. .