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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

Threads vs. Fork discussion

Answer 4

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

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

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

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

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

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

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 получать сигнал RST в сокете, что не происходит в Unix ,