Win32 rsync 포트의 기술적 장애물

Question

주로 Windows 사용자임에도 불구하고 저는 rsync의 열렬한 팬입니다.이제 저는 rsync의 장점을 다른 도구와 비교하고 싶지 않습니다...이것은 제 요점이 아닙니다.

Windows에서 rsync를 실행하는 방법 중 제가 찾은 유일한 방법은 Cygwin에서 실행되도록 구축된 버전을 이용하는 것입니다. Cygwin에는 유니코드와 관련된 문제가 있으므로 rsync도 마찬가지입니다.

rsync를 기본 Win32 바이너리로 포팅하는 데 실제 기술적 프로그래밍 장애물이 있는지 말할 수 있을 만큼 rsync의 작동에 대해 잘 아는 사람이 있습니까?

아니면 Windows 사용자들로부터 이식에 관심을 가질 만큼 충분한 관심이 없었기 때문일까요?

부분적으로는 포트를 시작하는 작업을 수행하려고 고려하고 있기 때문에 묻습니다. 하지만 포트가 불가능한 이유에 대해 제가 누락한 부분이 없는지 확인하고 싶습니다.

Answer 1

Windows에서 열린 파일을 잠그는 방식으로 인해 볼륨 섀도우 복사 서비스에 연결해야 하는 문제가 발생할 수 있습니다.

약 2년 전에 이 친구는 알고리즘을 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

당신은 이것을 본 적 있습니까:

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

나는 아무 문제 없이(그리고 일반적인 cygwin의 불행과 함께) cwrsync를 사용했지만 유니코드 파일 이름이 필요하지 않았기 때문에 그 문제를 본 적이 없습니다.

네이티브 Win32 포트가 없는 이유는 잘 모르겠지만 C#에서 유사한 델타 복사 시스템을 구현했기 때문에 얼마 전에 소스를 살펴보았습니다.뛰어난 *nix 해커의 세계에서 기대할 수 있듯이 소스는 대부분 단일 문자 변수 이름이며 주석이 전혀 없습니다. 이는 별로 도움이 되지 않으며 오히려 포터가 되려는 사람에게 불쾌감을 줄 수 있습니다.

Answer 4

나는 win32 포트를 수행하려는 노력도 평가해 왔습니다.나는 어떤 중요한 것이 그것을 막을 것이라고 믿지 않지만, 두 가지 모두에서 나온 증거는 rsync 메일링 리스트 또 다른 논의에서는 유닉스 fork() 시스템 호출에 대한 의존도가 높다는 점을 지적합니다.스레드를 사용하는 것은 win32로 가는 길로 보입니다.

스레드 대포크 토론

Answer 5

Visual Studio를 사용하여 구축할 수 있도록 MS-Windows에 대한 rsync 포트를 정말 감사하게 생각합니다.무작위로, 간헐적으로 다양한 프로토콜 오류가 발생합니다.나는 rsync를 사용하여 약 200대의 시스템으로 구성된 그리드에 sw를 배포하고 있으며 일반적으로 약 12개의 오류가 발생합니다.나는 rsync v3.0.7을 구축하기 위해 GCC 4.4.2와 최신 cygwin을 사용하고 있습니다.Cygwin이 필요하지 않은 버전을 실험해 볼 수 있다면 많은 도움이 될 것입니다.이는 그리드의 컴퓨터에 내가 가지고 있는 것과 다른 버전의 또 다른 cygwin 기반 앱이 이미 실행되고 있기 때문입니다.

rsyncv 메일링 리스트에서 시간을 보내본 결과 MS-Windows의 프로토콜 오류 원인에 대해서는 의견이 분분한 것 같습니다.어떤 사람들은 이것이 완전히 소켓 종료를 수행하지 못한 rsync의 버그라고 말합니다. 이 버그는 얼마 전에 수정되었습니다.다른 사람들은 클라이언트가 서버에 완료를 알리지 않고 종료되어 MW-windows 서버가 소켓에서 RST 신호를 받게 되는 rsync의 근본적인 프로토콜 오류라고 말합니다. 이는 Unix에서는 발생하지 않는 일입니다. .