macOS Sequoia में rsync को openrsync से बदला गया

 (derflounder.wordpress.com)
2 पॉइंट द्वारा GN⁺ 2025-04-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS में बिल्ट-इन file sync tool लंबे समय तक 2006 की नींव पर अटका रहा, और Apple ने rsync 2.6.9 को openrsync से बदल दिया
  • पहले का macOS rsync सुरक्षा और अन्य समस्याओं के लिए ज़रूरी fixes तो पाता रहा, लेकिन इसमें 2.6.9 के बाद की rsync 3.x features शामिल नहीं थीं
  • इस बदलाव की मुख्य वजह license का अंतर है: rsync 2.x GPLv2 के तहत वितरित होता है, जबकि rsync 3.x GPLv3 के तहत
  • openrsync, rsync के साथ compatible है, लेकिन यह सिर्फ कुछ command-line arguments को support करता है, इसलिए पुराने scripts Sequoia पर वैसे ही काम न करें
  • macOS 15.4 के अनुसार /usr/bin/rsync अब openrsync से जुड़ा है, इसलिए Mac admins को supported options और मौजूदा automation की compatibility जांचनी चाहिए

macOS में लंबे समय तक मौजूद रहा rsync 2.6.9

  • rsync Unix-आधारित operating systems में files transfer और sync करने का command-line tool है
    • इसे उसी computer से सीधे जुड़े storage devices के बीच इस्तेमाल किया जा सकता है
    • यह network पर मौजूद दूसरे computers के साथ files sync करने के लिए भी इस्तेमाल हो सकता है
  • macOS में लंबे समय से rsync शामिल था, लेकिन Apple द्वारा दिया गया version rsync 2.x का आख़िरी version rsync 2.6.9 था
  • rsync 2.6.9 नवंबर 2006 में जारी हुआ था, और rsync 3.x आने के बाद भी Apple ने macOS के rsync को उसके बाद के versions पर अपडेट नहीं किया
  • Apple ने macOS में शामिल rsync 2.6.9 के लिए सुरक्षा समस्याओं और अन्य मुद्दों पर ज़रूरी updates किए
  • लेकिन macOS Sequoia तक Apple का rsync लगभग 20 साल पुरानी नींव पर था, और 2.6.9 के बाद के rsync versions में जोड़ी गई नई features इसमें शामिल नहीं थीं

GPLv2 और GPLv3 की वजह से version वहीं रुका रहा

  • rsync 2.x और 3.x अलग-अलग GPL license versions के तहत वितरित होते हैं
    • rsync 2.x GPLv2 license के तहत है
    • rsync 3.x GPLv3 license के तहत है
  • Apple का मानना था कि वह rsync 2.x की GPLv2 शर्तों का पालन कर सकता है, लेकिन rsync 3.x की GPLv3 शर्तों का पालन नहीं कर सकता
  • इसी वजह से macOS में rsync 3.x उपलब्ध नहीं कराया गया

macOS Sequoia में openrsync पर स्विच

  • macOS Sequoia में Apple ने rsync 2.6.9 को openrsync से बदल दिया
  • openrsync ऐसा rsync implementation है जो GPL license का उपयोग नहीं करता
  • openrsync को BSD-परिवार के licenses में से एक ISC license के तहत वितरित किया जाता है
  • ISC license एक permissive license है, जो इससे जुड़े software के उपयोग, संशोधन और वितरण पर न्यूनतम पाबंदियां लगाता है
  • Apple का मानना था कि rsync 3.x की GPLv3 शर्तों के विपरीत वह openrsync की license शर्तों का पालन कर सकता है

Mac admins के लिए अहम compatibility अंतर

  • Apple अब rsync की GPL compliance समस्या की चिंता किए बिना openrsync के updated versions दे सकता है
  • उससे भी बड़ा व्यावहारिक बदलाव यह है कि openrsync, rsync के साथ compatible होने के बावजूद rsync command-line arguments का सिर्फ एक हिस्सा स्वीकार करता है
  • जो rsync features पहले macOS पर काम करती थीं, वे macOS Sequoia में fail हो सकती हैं
    • क्योंकि संभव है कि वे features Sequoia में शामिल openrsync command-line tool में मौजूद न हों
  • macOS Sequoia के openrsync में कौन-सी features supported हैं, यह openrsync manual page में देखा जा सकता है

macOS 15.4 में इसे कैसे जांचें

  • macOS 15.4 के अनुसार openrsync tool /usr/bin/rsync से जुड़ा हुआ है
  • users पहले की तरह rsync command-line tool चलाने की तरह ही openrsync चला सकते हैं
  • openrsync की version जानकारी इस command से देखी जा सकती है
/usr/bin/rsync --version
  • output कुछ इस तरह दिखेगा
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
  • output में protocol version 29 और rsync version 2.6.9 compatible दिखता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-04-07
Hacker News की राय

  • openrsync के दस्तावेज़ इतने कमजोर हैं कि भरोसा नहीं बनता कि यह rsync की जगह ले सकता है
    अगर कोई file copy प्रोग्राम है, तो उसे source के data और metadata का एक भी bit खोए बिना पूरी copy करने में सक्षम होना चाहिए; नहीं तो मेरे हिसाब से वह इस्तेमाल लायक नहीं है
    Unix जैसे कई copy/archive tools default options के साथ पूरी copy नहीं कर पाते, और कुछ tools में तो किसी भी option से यह संभव नहीं होता
    scp भी कम से कम कुछ साल पहले तक अलग operating system या filesystem के बीच पूरी copy करने में मुश्किल देता था, इसलिए मैंने उसे इस्तेमाल नहीं किया और ssh के ऊपर सिर्फ rsync ही इस्तेमाल करता रहा
    rsync उन दुर्लभ tools में है जो सही options देने पर FreeBSD UFS और Linux XFS जैसे अलग operating system/filesystem के बीच भी extended attributes, ACL और high-precision timestamps तक सुरक्षित रखता है
    openrsync के दस्तावेज़ ऐसी पूरी copy की गारंटी नहीं देते, इसलिए फिलहाल मैं मानता हूँ कि यह नहीं कर सकता और इसे बेकार मानता हूँ
    archive के मामले में, Linux पर bsdtar जब pax format इस्तेमाल करता है तो लगभग पूरी file copy store कर सकता है, जबकि पुराने tar/cpio formats आधुनिक metadata नहीं रख सकते
    रोज़मर्रा में मैंने rsync को /usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY" के रूप में alias कर रखा है
    coreutils का cp भी सही CLI options और compile options के साथ पूरी copy कर सकता है, लेकिन कुछ distributions इसे extended attributes support के बिना build करते हैं, जिससे बिना warning या error के सिर्फ partial copy होती है

    • backup कंपनी में काम करके देखा तो बड़े enterprise customers में ज़्यादातर restore के समय 99% metadata सही वापस आता है या नहीं, इसकी ज्यादा परवाह नहीं करते; data restore हो जाए तो वे ठीक मानते हैं
      हम बहुत सावधानी से सब कुछ restore करते हैं, लेकिन कभी-कभी लगता है कि इसकी चिंता सिर्फ हमें ही है
    • यह सिर्फ documentation style का फर्क भी हो सकता है
      मूल रूप से openrsync को मैं कम license restrictions वाला rsync समझूँगा, यह नहीं मानूँगा कि यह अलग तरह से काम करता है
      openrsync README में कहा गया है कि यह rsync compatible है और rsync documentation देखने को कहा गया है
      अगर extended attributes, ACL और high-resolution timestamps protocol level पर optional features नहीं हैं, तो compatibility का दावा करने के लिए modern rsync जो कुछ support करता है, वह सब support करना चाहिए—ऐसा लगता है
      वरना जिज्ञासा है कि क्या इसका मतलब यह है कि पूरा protocol accept करते हुए ACL जैसी चीज़ों को बस छोड़ दिया जाता है
    • OpenRsync OpenBSD project से आया है, इसलिए आम तौर पर quality और security पर focus की उम्मीद बनती है
      हालांकि official website पर भी “We are still working on it... so please wait.” लिखा है
    • Apple के नज़रिए से यह license issue है, और इस फर्क की परवाह करने वाले users कम होंगे
      ऐसे users बस rsync install कर सकते हैं
    • openrsync जिन arguments को accept करता है, उनकी list source code में मिल गई
      alias में इस्तेमाल होने वाले --xattrs, --acls, --hard-links तीनों गायब हैं
      [0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...

  • अपेक्षाकृत नए Linux user के तौर पर, bundled system utilities की version management काफ़ी गड़बड़ लगती है
    एक प्रमुख उदाहरण unzip है: Debian server और पुराने Ubuntu server के bundled unzip AES-256 से encrypted ZIP को handle नहीं कर पाए, लेकिन Stack Overflow देखने पर लगता है कि कुछ distributions ने इसे support करने के लिए update किया है
    समस्या यह है कि updated unzip आसानी से मिलना मुश्किल है, सभी “version 6.00” होने का दावा करते हैं लेकिन असल behavior अलग है, और मिल भी जाए तो यह पता नहीं कि system bundle को replace करना safe है या नहीं
    अंत में, भले ही किसी ने किसी widely used utility में अच्छा feature जोड़ दिया हो, फिर भी उसे इस्तेमाल नहीं कर पाते; उल्टा core system utility होने की वजह से इसे third-party tool से ज़्यादा update करना मुश्किल लगता है
    Windows या macOS भी system utilities के मामले में similar या worse हो सकते हैं, लेकिन लगा था कि Linux ऐसी चीज़ों को बेहतर handle करेगा

    • इस case में unzip की जगह 7z इस्तेमाल करना बेहतर है
      Linux पर ZIP या compressed files generally handle करते समय unzip इस्तेमाल करने की याद लगभग नहीं है
      Unix philosophy के हिसाब से tar से bundle करना, gzip से compress करना और pgp से encrypt करना—यानी एक काम अच्छी तरह करने वाले simple tools को pipe से जोड़ना—भी natural flow है
      version के मामले में Debian/Ubuntu दोनों 6.00 क्यों कहते हैं, यह पक्का नहीं, लेकिन यह सामान्य बात नहीं है
      personal machine हो तो Arch या Manjaro जैसे rolling release distributions upstream versions को ज़्यादा लगातार follow करते हैं, लेकिन maintenance burden और खुद manage करने की expectations बढ़ जाती हैं
      Linux/open source version management में ज़्यादा परेशान करने वाली बात यह है कि libraries v1.00 declare करने को बहुत टालती हैं
      ecosystem में widely embedded, stable और features भी लगभग complete होने के बावजूद वे v0.2 या v0.68 पर सालों तक रुकी रहती हैं, जिससे beginners confuse होते हैं
    • Debian और Ubuntu system tool versions को operating system release version से बांधकर रखने की tendency रखते हैं
      Debian का release cycle लंबा है, लेकिन यह बहुत stable है, और stable में सब कुछ अच्छी तरह fit होकर चलता है
      Ubuntu मूल रूप से Debian में “अगर releases ज़्यादा frequent हों तो?” जोड़ने जैसा लगता है
      अगर latest tools चाहिए, तो Nix या Arch जैसे कम stable हो सकने वाले विकल्पों को स्वीकार करना पड़ता है, और दोनों बहुत user-friendly नहीं हैं
      stability और latest tools दोनों चाहिए तो Gentoo एक रास्ता है, लेकिन वह Arch से भी ज़्यादा भारी पड़ता है
      stability और simplicity चाहिए तो disk space की कीमत पर Docker/podman, flatpak, appcontainers, snap जैसे तरीके इस्तेमाल कर सकते हैं
      Windows और Mac में भी यही समस्या है, और Windows पुराने libraries साथ में ship करके और running app के हिसाब से dynamic link करके इसे solve करता आया है
    • unzip एक special case है
      upstream development basically रुक चुका है और last release 2009 का 6.0 है
      इसके बाद कई issues मिले और features भी कम पड़ने लगे, तो हर distribution ने उस release पर ढेर सारे patches चढ़ाए, और नतीजतन एक ही version number वाले बहुत अलग executables बन गए
      [0]: https://infozip.sourceforge.net/UnZip.html
      [1]: Arch build recipe देखने पर लागू होने वाले patches की संख्या दिखती है: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
    • distributions independent projects हैं, इसलिए ऐसे differences expected हैं
      कुछ हद तक interoperability अच्छी है, लेकिन अलग-अलग choices होना भी एक advantage है
      ज़्यादातर distribution repositories में bsdtar होता है, इसलिए उसकी जगह उसे आज़माया जा सकता है, और distribution के हिसाब से package name libarchive हो सकता है
      सिर्फ़ bsdtar xf path/to/file से लगभग सभी formats extract किए जा सकते हैं और यह ZIP के AES को भी support करता है
      macOS में यह by default शामिल है और Windows में भी शायद शामिल होगा
    • यह सच में messy है, और जितना हो सके built-in tools पर कम निर्भर रहना बेहतर है
      हर काम के लिए git repository और flake.nix बनाते हैं, और direnv को उस directory में जाते समय flake में declared environment activate करने देते हैं
      अगर grep इस्तेमाल करने वाली script लिखते हैं, तो script को repository में डालते हैं और pkgs.gnugrep को भी flake.nix में add करते हैं
      इससे system version नहीं, बल्कि declared version इस्तेमाल होता है, और macOS से Linux या WSL पर जाने पर भी वही grep version call होता है
      Nix को beginners के लिए unfriendly कहा जाता है, इसलिए सीधे recommend करना थोड़ा सावधानी का विषय है, लेकिन core point यह है कि dependencies को किसी न किसी तरह declare करें और सिर्फ़ declared dependencies ही इस्तेमाल करें
      Docker भी possible है, और Python/Node.js/Go/Rust जैसे language ecosystems भी dependencies bundle और call करने के तरीके देते हैं
      ऐसा करने से dependency updates commits में बचते हैं, और कुछ टूटने पर previous commit पर वापस जा सकते हैं
      ऐसा repository ज़रूरी नहीं कि software project ही हो; यह “XYZ करते समय चाहिए tools का collection” भी हो सकता है

  • openrsync का rsync की कुछ सुविधाओं को support न करना थोड़ा परेशान करने वाला है
    फिर भी अब rsync के independent implementations कई हो गए हैं, यह अच्छी बात है
    क्योंकि इसका मतलब है कि rsync को सिर्फ एक software नहीं, बल्कि असल में एक protocol की तरह treat किया जा रहा है

    • यह बात उम्मीद जगाती है
      अगर यह protocol के करीब जाता है, तो rsync algorithm आधारित binary diff API के मौके भी निकल सकते हैं
      दिलचस्प बात यह है कि Dropbox internally rsync binary diff का इस्तेमाल करके बड़ी files में छोटे changes को जल्दी upload करता था
      मुझे लगता है अब भी करता होगा, लेकिन public API endpoint में यह feature नहीं है, इसलिए बड़ी file में सिर्फ छोटा बदलाव हो तब भी पूरी file दोबारा upload करनी पड़ती है
    • http://github.com/stapelberg/rsync-over-grpc/ देखें तो rsync protocol, ठीक-ठीक कहें तो https://github.com/gokrazy/rsync implementation को gRPC के ऊपर इस्तेमाल करने का example है
      company environment में जब SSH+rsync blocked हो लेकिन gRPC service बनाना allowed हो, तो यह काफी उपयोगी होता है
    • website पर “We are still working on it... so please wait.” लिखा है
      rsync में features बहुत हैं, इसलिए इसमें काफी समय लगना ही है
    • librsync भी है
    • यह क्यों बताता है कि rsync एक protocol है, यह जानने की उत्सुकता है

  • mainline rsync patch में macOS metadata support के लिए extended attributes support जोड़ा गया था
    Bombich का “Carbon Copy Cloner” इसे wrap करने वाला GUI app है
    https://support.bombich.com/hc/en-us/articles/20686446501143...
    Mike Bombich के बारे में macOS Server system administrator bulletin board की पोस्ट से पता चला था, और संबंधित material भी है
    https://web.archive.org/web/20140707182312/http://static.afp...
    Nathaniel Gray ने Backup Bouncer बनाया था, जो multiple streams, extended attributes, ACL आदि सहित backup की fidelity verify करता है
    https://github.com/n8gray/Backup-Bouncer
    rsync को wrap करने वाला SwiftUI app RsyncX भी है
    https://github.com/rsyncOSX/RsyncOSX
    नए UNIX system के ऊपर “Classic” macOS software चलाने के दौर में इन चीजों को सच में बहुत महत्वपूर्ण माना जाता था
    https://web.archive.org/web/20161022012615/http://blog.plast...

    • rsync की समस्या यह है कि यह अविश्वसनीय रूप से धीमा है
      IFileOperation(Windows) और FileManager(macOS) underlying filesystem द्वारा supported सबसे performant copy करते हैं
      SMB और ReFS में CRC check बस checkbox जैसी चीज है, और modern Windows Server के modern SMB share में rsync का content matching phase duplicate काम है
      Windows-to-Windows में IFileOperation का throughput rsync से 1.5~8 गुना तेज और CPU usage कम होता है, और यह सामान्य Go file copy से भी 1.2~3 गुना तेज हो सकता है
      अगर जटिल filesystem metadata सच में इस्तेमाल करने वाले operating systems की परवाह न करके सिर्फ Linux देखें, तो openrsync या कोई और simpler program काफी है

  • उत्सुकता है कि क्या कोई ऐसी अच्छी सामग्री है जो समझाती हो कि Apple GPLv3 से इतना डरता क्यों है
    executable को statically compile कर दिया जाए तो समस्या नहीं होनी चाहिए, ऐसा लगता है

    • GPLv3 ने वह loophole बंद किया था जिसमें GPL code से निकले product का source तो release कर दिया जाता था, लेकिन user उस source को actual device पर build करके run नहीं कर सकता था
      उस समय TiVo ने ऐसा किया था, इसलिए इसे tivoization कहा गया
      iOS में GPLv3 इस्तेमाल न करने की वजह साफ है, क्योंकि इससे conditions violate होंगी
      macOS में GPLv3 code रखा जा सकता होगा, लेकिन Apple iOS/macOS/watchOS/tvOS/visionOS के बीच बहुत code share करता है, इसलिए एक operating system में ही GPLv3 पर निर्भर होना और बाकी में न इस्तेमाल करना खास मायने नहीं रखता
      बिल्कुल न इस्तेमाल करना ही सरल है
      साथ ही भविष्य में अगर macOS में user code execution को और lock down किया जाए, तो उस समय GPLv3 code निकालने की चिंता नहीं करनी पड़ेगी
    • GPL और related licenses पर मेरा नजरिया lawyers के साथ काम करते हुए काफी बदल गया
      जिन चीजों को मैं पूरी तरह safe मानता था, lawyers के नजरिए से वे इतनी निश्चित नहीं थीं
      Apple की वजह मुझे नहीं पता, लेकिन दूसरी company के corporate lawyers ने सिद्धांत दिया था कि जहां संभव हो, non-GPL licenses चुनें
    • शायद वे GPLv3 को court में challenge करने और संभवतः हारने तक की स्थिति से ही बचना चाहते हैं
      GPLv2 से जुड़े case law history को देखें तो लगाए गए effort के मुकाबले मिलने वाला फायदा कम लगता है
      Apple के नजरिए से जो हिस्सा “problem” दिखता है, उसे बस replace कर देने से पूरी problem category से बचा जा सकता है
    • Apple स्पष्ट रूप से user rights के खिलाफ है, और GPL वही rights protect करने वाली license है
      detailed technical issues दिलचस्प हो सकते हैं, लेकिन मेरे हिसाब से वे core point नहीं हैं
    • Apple वजह नहीं बताता
      Apple के इरादों पर दूसरे लोगों की explanations पर भरोसा न करना बेहतर है

  • जब मैं खुद https://github.com/gokrazy/rsync implementation Go में लिख रहा था, तब मैंने openrsync देखा था, और code अच्छा लगा
    हालांकि यह अफसोस की बात है कि openrsync, rsync के साथ 100% compatible नहीं है
    macOS 15 पर मेरे tests टूटने पर पता चला कि Apple ने openrsync पर switch करना शुरू कर दिया है

  • कहा गया है कि openrsync को OpenBSD के लिए RPKI validator rpki-client(1) project के हिस्से के रूप में लिखा गया था और NetNod, IIS.SE, SUNET, 6connect ने funding दी थी; सोच रहा हूं कि इन organizations ने इस development को fund क्यों किया
    https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...

    • इसके अस्तित्व की वजह यह comment काफी अच्छी तरह समझाता है
      https://news.ycombinator.com/item?id=43605846
      कंपनियां उन चीजों को fund करती हैं जो उपयोगी या जरूरी होती हैं
      list में शामिल कुछ कंपनियां BSD इस्तेमाल कर रही हो सकती हैं, और संभव है कि उन्हें GPLv3 न होने वाला rsync implementation चाहिए था या इसकी जरूरत थी
      या हो सकता है कि वे बस open source projects और development को sponsor करने में रुचि रखती हों

  • कुछ समय तक Sequoia 15.3 तक /var/select/rsync या environment variable CHOSEN_RSYNC के जरिए rsync_samba और rsync_openrsync दोनों इस्तेमाल किए जा सकते थे
    openrsync की एक खास तौर पर झुंझलाने वाली बात यह थी कि वह --relative के लिए /./ magic path element support करने का दावा करता था
    इस issue पर मैंने करीब एक महीने पहले Apple को bug report भेजी थी
    Sequoia 15.4 से rsync_samba हट गया, और मैंने rsync को Homebrew से install कर रखा है

  • हाल ही में मुझे यह problem हुई: command line पर xcodebuild से iOS .ipa बनाते समय लगता है कि वह अंदर से rsync को call करके local directories के बीच files copy करता है
    लेकिन $PATH में Homebrew rsync आगे था, इसलिए वही run हुआ, और xcodebuild ने openrsync-specific argument --extended-attributes pass किया
    Homebrew rsync उस argument को समझ नहीं पाया, इसलिए fail होकर exit हो गया

  • यह अब भी अच्छी बात है कि Apple, osx को iOS जैसा बनाने के लिए POSIX aspect को धीरे-धीरे हटाने के बजाय, उसे लगातार improve और अपनाता जा रहा है