العقبات الفنية لمنفذ Win32 rsync

Question

على الرغم من كوني أحد مستخدمي Windows في المقام الأول، إلا أنني من أشد المعجبين بـ rsync.الآن، لا أريد أن أجادل حول فضائل rsync مقابل أي أداة أخرى... هذه ليست وجهة نظري.

الطريقة الوحيدة التي وجدتها لتشغيل rsync على نظام التشغيل windows هي عبر إصدار تم تصميمه للتشغيل أعلى Cygwin، وبما أن Cygwin لديه مشكلات مع Unicode، فإن rsync كذلك.

هل هناك أي شخص على دراية كافية بطريقة عمل rsync ليقول ما إذا كانت هناك أي عقبات برمجية تقنية حقيقية لنقل rsync إلى ثنائي Win32 الأصلي؟

أم أنه ربما لم يكن هناك أبدًا اهتمام كافٍ من مستخدمي Windows للاهتمام بنقله؟

أسأل ذلك جزئيًا لأنني أفكر في محاولة تولي مهمة بدء تشغيل المنفذ، ولكنني أريد التأكد من عدم وجود شيء أفتقده فيما يتعلق بالسبب الذي قد يجعل ذلك غير ممكن.

Answer 1

قد تتسبب الطريقة التي يقوم بها Windows بتأمين الملفات المفتوحة في حدوث مشكلة تتطلب منك الاتصال بخدمة Volume Shadowcopy Service.

منذ حوالي عامين، قام هذا الزميل بنقل الخوارزمية إلى لغة C#.لم ألقي نظرة على الكود (أو الكود الثنائي المقدم)، ولكن قد يكون مكانًا لبدء البحث أو شخص ما لمحاولة الاتصال به.
http://www.russiantequila.com/wordpress/?p=8

Answer 2

(تنصل:أعدك أنني لا أبحث عن جوجل بنفسي، لكن تحليلات جوجل هي التي أوصلتني إلى هنا)

لقد قمت بنقل rsync إلى .net (رابط sig11 هو مدونتي).لا توجد عقبات فنية، بل فقط عقبات عملية.كما قيل بالفعل، الكود هو بالأحرى ...كثيف.من الصعب المتابعة، والافتقار التام للتعليقات.أنا أكثر من سعيد بإتاحة عملي، ولكن لسوء الحظ، نظرًا لأنه كان جزءًا من جهد تجاري، فهو ليس في حالة أفضل بكثير.

لقد عبثت، في عدد من المناسبات، بفكرة الهندسة العكسية للبروتوكول وتنفيذ تنفيذ شامل متوافق مع البروتوكول الحالي، ولكن...أنظف قليلاً للعمل معه.لقد قمت بإنشاء موقع ويكي لهذا الغرض، ولكن...كما ترون من نقص المحتويات هناك، تم أخذ الأولوية للعناصر الأخرى.إذا كان أي شخص يرغب في العمل معي في هذا الشأن، فقد يكون هذا هو الدافع الذي أحتاجه للمضي قدمًا.

إن مفهوم الأداة رائع، وكذلك الوظيفة التي تقدمها، إلا أنها محدودة إلى حد ما خارج مساحة *ix، ويمكن أن تستفيد بالتأكيد من واجهة برمجة التطبيقات.

رابط ويكي للرجوع إليها:

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

Answer 3

هل رأيت ذلك من قبل:

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

لقد استخدمت cwrsync دون أي مشكلة (ومع الكثير من بؤس cygwin المعتاد)، لكن لم تكن لدي أي حاجة لأسماء ملفات Unicode، لذلك لم أر هذه المشكلة.

لا أعرف حقًا سبب عدم وجود منفذ Win32 أصلي، لكنني ألقيت نظرة على المصدر منذ فترة لأنني قمت بتطبيق نظام نسخ دلتا مشابه في لغة C#.كما يتوقع المرء من عالم قراصنة *nix اللامعين، فإن المصدر هو إلى حد كبير أسماء متغيرة مكونة من حرف واحد وغياب تام للتعليقات، وهو أمر غير مفيد للغاية وقد يكون منفرًا إلى حد ما للحمالين المحتملين.

Answer 4

لقد قمت بتقييم الجهود المبذولة لتنفيذ منفذ Win32 أيضًا.لا أعتقد أن أي شيء كبير من شأنه أن يمنع ذلك، ولكن الأدلة من كليهما القائمة البريدية rsync وتشير مناقشة أخرى إلى الاعتماد الكبير على استدعاءات نظام Unix fork().يبدو أن استخدام سلاسل الرسائل هو الطريق الصحيح لـ Win32.

المواضيع مقابل.مناقشة شوكة

Answer 5

سأكون ممتنًا حقًا لوجود منفذ rsync لنظام التشغيل MS-Windows بحيث يمكن إنشاؤه باستخدام Visual Studio.أواجه أخطاء بروتوكولية مختلفة بشكل عشوائي، بشكل متقطع إلى حد ما.أنا أستخدم rsync لتوزيع sw على شبكة مكونة من حوالي 200 جهاز وعادةً ما أواجه حوالي عشرة حالات فشل.أنا أستخدم دول مجلس التعاون الخليجي 4.4.2 وأحدث cygwin لبناء rsync v3.0.7.سيكون من المفيد لي كثيرًا أن أتمكن من تجربة إصدار لا يتطلب cygwin.وذلك لأن الأجهزة الموجودة في الشبكة لديها بالفعل تطبيق آخر قائم على cygwin قيد التشغيل وهو إصدار مختلف عن الإصدار الذي أستخدمه.

بعد قضاء بعض الوقت في القائمة البريدية لـ rsynv، يبدو أن الرأي منقسم حول سبب أخطاء البروتوكول على نظام التشغيل MS-Windows.يقول البعض إنه خطأ في rsync حيث فشل في إيقاف تشغيل مأخذ التوصيل النظيف، وهو خطأ تم إصلاحه منذ فترة.يقول آخرون إنه خطأ بروتوكول أساسي في rsync حيث لا يخبر العميل الخادم بأنه قد انتهى، بل يتم إيقاف تشغيله فقط، مما يتسبب في حصول خوادم MW-windows على إشارة RST على المقبس، وهو أمر لا يحدث في Unix .