- ในสถานการณ์ที่เครื่องมือซิงก์ไฟล์ซึ่งฝังมากับ macOS ยังคงค้างอยู่บนฐานจากปี 2006 ทาง Apple ได้เปลี่ยน rsync 2.6.9 เป็น openrsync
- rsync เดิมบน macOS แม้จะได้รับการแก้ไขที่จำเป็นด้านความปลอดภัยและปัญหาอื่น ๆ แต่ไม่ได้รวม ฟีเจอร์ของ rsync 3.x ที่มีหลังจาก 2.6.9
- เบื้องหลังหลักของการเปลี่ยนผ่านนี้คือความแตกต่างของไลเซนส์ โดย rsync 2.x เผยแพร่ภายใต้ GPLv2 และ rsync 3.x เผยแพร่ภายใต้ GPLv3
- openrsync เข้ากันได้กับ rsync แต่รองรับ อาร์กิวเมนต์บรรทัดคำสั่งเพียงบางส่วน เท่านั้น ดังนั้นสคริปต์เดิมอาจไม่ทำงานแบบเดิมบน Sequoia
- ณ macOS 15.4,
/usr/bin/rsync ถูกชี้ไปที่ openrsync ดังนั้นผู้ดูแลระบบ Mac ควรตรวจสอบ ความเข้ากันได้ ของออปชันที่รองรับและระบบอัตโนมัติเดิม
rsync 2.6.9 ที่คงอยู่บน macOS มาอย่างยาวนาน
- rsync เป็นเครื่องมือบรรทัดคำสั่งสำหรับส่งและซิงก์ไฟล์บนระบบปฏิบัติการตระกูล Unix
- ใช้ได้ระหว่างอุปกรณ์จัดเก็บข้อมูลที่เชื่อมต่อโดยตรงกับคอมพิวเตอร์เครื่องเดียวกัน
- และยังใช้ซิงก์ไฟล์กับคอมพิวเตอร์เครื่องอื่นบนเครือข่ายได้ด้วย
- macOS มี rsync รวมมาเป็นเวลานาน แต่เวอร์ชันที่ Apple ให้มาคือ rsync 2.6.9 ซึ่งเป็น เวอร์ชันสุดท้ายของ rsync 2.x
- rsync 2.6.9 เปิดตัวในเดือนพฤศจิกายน 2006 และแม้หลังจาก rsync 3.x ออกมาแล้ว Apple ก็ไม่ได้อัปเกรด rsync บน macOS ไปเป็นเวอร์ชันหลังจากนั้น
- Apple ยังคงอัปเดต rsync 2.6.9 ที่รวมอยู่ใน macOS เท่าที่จำเป็นสำหรับปัญหาด้านความปลอดภัยและปัญหาอื่น ๆ
- อย่างไรก็ตาม จนถึงก่อน macOS Sequoia rsync ของ Apple ก็ยังยึดอยู่กับ ฐานที่มีอายุเกือบ 20 ปี และไม่ได้รวมฟีเจอร์ใหม่ที่เพิ่มเข้ามาใน rsync เวอร์ชันหลัง 2.6.9
การค้างอยู่ที่เวอร์ชันเดิมจาก GPLv2 และ GPLv3
- rsync 2.x และ 3.x ถูกเผยแพร่ภายใต้ เวอร์ชัน GPL ที่ต่างกัน
- Apple เห็นว่าสามารถปฏิบัติตามเงื่อนไขของ GPLv2 สำหรับ rsync 2.x ได้ แต่ตัดสินว่าไม่สามารถปฏิบัติตามเงื่อนไขของ GPLv3 สำหรับ rsync 3.x ได้
- ด้วยเหตุนี้ macOS จึงไม่ได้มี rsync 3.x มาให้
การเปลี่ยนไปใช้ openrsync ใน macOS Sequoia
- ใน macOS Sequoia ทาง Apple ได้แทนที่ rsync 2.6.9 ด้วย openrsync
- openrsync เป็นอิมพลีเมนเทชันของ rsync ที่ไม่ใช้ไลเซนส์ GPL
- openrsync เผยแพร่ภายใต้ ISC license ซึ่งเป็นหนึ่งในไลเซนส์สาย BSD
- ISC license เป็นไลเซนส์แบบ permissive ที่มีข้อจำกัดน้อยมากต่อการใช้งาน การแก้ไข และการแจกจ่ายซอฟต์แวร์ที่ใช้ไลเซนส์นี้
- Apple มองว่าสามารถปฏิบัติตามเงื่อนไขของไลเซนส์ openrsync ได้ ต่างจากเงื่อนไข GPLv3 ของ rsync 3.x
ความต่างด้านความเข้ากันได้ที่สำคัญสำหรับผู้ดูแลระบบ Mac
- ต่อไป Apple สามารถจัดส่ง openrsync เวอร์ชันอัปเดตได้โดยไม่ต้องกังวลเรื่อง การปฏิบัติตาม GPL ของ rsync
- แต่การเปลี่ยนแปลงเชิงปฏิบัติที่สำคัญกว่าคือ แม้ openrsync จะเข้ากันได้กับ rsync แต่ อนุญาตเฉพาะบางส่วนของอาร์กิวเมนต์บรรทัดคำสั่งของ rsync
- ฟังก์ชัน rsync ที่เคยทำงานบน macOS เดิม อาจล้มเหลวบน macOS Sequoia
- เพราะฟังก์ชันนั้นอาจไม่มีอยู่ในเครื่องมือบรรทัดคำสั่ง openrsync ที่มากับ Sequoia
- สามารถตรวจสอบฟังก์ชันที่รองรับใน openrsync บน macOS Sequoia ได้จาก หน้าแมนนวลของ openrsync
วิธีตรวจสอบบน macOS 15.4
- ณ macOS 15.4 เครื่องมือ openrsync ถูกชี้อยู่ที่
/usr/bin/rsync
- ผู้ใช้จึงสามารถเรียกใช้ openrsync ได้เหมือนกับการเรียกใช้เครื่องมือบรรทัดคำสั่ง rsync แบบเดิม
- สามารถตรวจสอบข้อมูลเวอร์ชันของ openrsync ได้ด้วยคำสั่งต่อไปนี้
/usr/bin/rsync --version
- เอาต์พุตจะมีลักษณะใกล้เคียงดังนี้
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
- ในเอาต์พุตจะมีการแสดง protocol version 29 และ rsync version 2.6.9 compatible
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เอกสารของ openrsync มีน้อยเกินไป จนไม่เกิดความเชื่อมั่นว่ามันจะมาแทน rsync ได้
ถ้าเป็นโปรแกรมคัดลอกไฟล์ ก็ควรต้องทำ การคัดลอกแบบสมบูรณ์ ที่ไม่สูญเสียข้อมูลและเมทาดาทาของต้นฉบับแม้แต่บิตเดียวได้ หากทำไม่ได้ก็ถือว่าใช้งานไม่ได้
เครื่องมือคัดลอก/เก็บถาวรจำนวนมากในตระกูล Unix ไม่สามารถคัดลอกได้อย่างสมบูรณ์ด้วยตัวเลือกพื้นฐาน และบางเครื่องมือก็ทำไม่ได้ไม่ว่าจะใช้ตัวเลือกใดก็ตาม
อย่างน้อยจนถึงไม่กี่ปีก่อน scp ก็ยังคัดลอกแบบสมบูรณ์ได้ยากเมื่อระบบปฏิบัติการหรือระบบไฟล์ต่างกัน จึงไม่ได้ใช้ และใช้เฉพาะ rsync บน ssh มาโดยตลอด
rsync เป็นเครื่องมือที่พบได้ยากซึ่งถ้าใส่ตัวเลือกที่เหมาะสม จะยังคงรักษา extended attributes, ACL และ timestamp ความละเอียดสูงไว้ได้ แม้ระหว่างระบบปฏิบัติการ/ระบบไฟล์ที่ต่างกัน เช่น ระหว่าง FreeBSD UFS กับ Linux XFS
เอกสารของ openrsync ไม่ได้รับประกันการคัดลอกแบบสมบูรณ์เช่นนี้ ดังนั้นตอนนี้จึงถือไว้ก่อนว่าทำไม่ได้และตัดสินว่าไม่มีประโยชน์
ฝั่งงาน archive บน Linux เมื่อ bsdtar ใช้รูปแบบ pax จะสามารถเก็บการคัดลอกไฟล์ที่เกือบสมบูรณ์ได้ ส่วนรูปแบบ tar/cpio แบบเก่าไม่สามารถเก็บเมทาดาทาสมัยใหม่ได้
ปกติจะตั้ง alias ให้ rsync เป็น
/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"cpของ coreutils ก็สามารถคัดลอกได้สมบูรณ์ถ้าใช้ตัวเลือก CLI และตัวเลือกตอนคอมไพล์ที่ถูกต้อง แต่บางดิสโทร build มาโดยไม่มีการรองรับ extended attributes ทำให้คัดลอกได้เพียงบางส่วนโดยไม่มีคำเตือนหรือข้อผิดพลาดพวกเรากู้คืนทุกอย่างอย่างระมัดระวังมาก แต่บางครั้งก็รู้สึกเหมือนมีแค่พวกเราเท่านั้นที่ใส่ใจ
โดยพื้นฐานแล้วน่าจะมอง openrsync ว่าเป็น rsync ที่มีข้อจำกัดด้านไลเซนส์น้อยกว่า ไม่ใช่ว่าทำงานต่างออกไป
ใน README ของ openrsync ระบุว่าเข้ากันได้กับ rsync และให้ดูเอกสารของ rsync
ถ้า extended attributes, ACL และ timestamp ความละเอียดสูงไม่ใช่ฟีเจอร์ทางเลือกในระดับโปรโตคอล การอ้างว่าเข้ากันได้ก็ควรต้องรองรับทุกอย่างที่ rsync สมัยใหม่รองรับไม่ใช่หรือ
ไม่อย่างนั้นก็สงสัยว่าหมายถึงรับโปรโตคอลทั้งหมด แต่ทิ้งสิ่งอย่าง ACL ไปเฉย ๆ หรือเปล่า
อย่างไรก็ตาม แม้แต่เว็บไซต์ทางการก็ยังเขียนว่า “We are still working on it... so please wait.”
ผู้ใช้แบบนั้นก็แค่ติดตั้ง rsync เองก็ได้
--xattrs,--acls,--hard-linksที่ใช้ใน alias นั้นหายไปทั้งหมด[0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...
ในฐานะผู้ใช้ Linux ที่ค่อนข้างใหม่ ผมรู้สึกว่า การจัดการเวอร์ชัน ของยูทิลิตีระบบที่บันเดิลมานั้นค่อนข้างเละเทะ
ตัวอย่างเด่นคือ
unzipโดยunzipที่บันเดิลมากับเซิร์ฟเวอร์ Debian และเซิร์ฟเวอร์ Ubuntu รุ่นเก่าไม่สามารถจัดการ ZIP ที่เข้ารหัสด้วย AES-256 ได้ แต่ดูจาก Stack Overflow แล้วดูเหมือนว่าบางดิสโทรจะอัปเดตให้รองรับสิ่งนี้แล้วปัญหาคือหา
unzipที่อัปเดตแล้วได้ไม่ง่าย ทุกตัวอ้างว่าเป็น “version 6.00” แต่พฤติกรรมจริงต่างกัน และแม้จะหาเจอก็ไม่รู้ว่าการแทนที่ตัวที่บันเดิลมากับระบบจะปลอดภัยหรือไม่สุดท้าย แม้จะมีใครเพิ่มฟีเจอร์ดี ๆ ให้ยูทิลิตีที่ใช้กันแพร่หลาย ก็ยังใช้ไม่ได้อยู่ดี และเพราะมันเป็นยูทิลิตีระบบหลัก จึงรู้สึกว่ากลับอัปเดตยากกว่าเครื่องมือจากภายนอกเสียอีก
Windows หรือ macOS อาจคล้ายกันหรือแย่กว่านี้ในแง่ยูทิลิตีระบบ แต่ผมคิดว่า Linux น่าจะจัดการเรื่องแบบนี้ได้ดีกว่านี้
unzipบน Linux ผมแทบจำไม่ได้ว่าเคยใช้
unzipเวลาจัดการ ZIP หรือไฟล์บีบอัดโดยรวมตามปรัชญา Unix การใช้เครื่องมือเรียบง่ายที่ทำงานอย่างเดียวให้ดี แล้วต่อกันด้วยไพป์ เช่น มัดไฟล์ด้วย tar บีบอัดด้วย gzip และเข้ารหัสด้วย pgp ก็เป็นแนวทางที่เป็นธรรมชาติ
เรื่องเวอร์ชันนั้นไม่แน่ใจว่าทำไม Debian/Ubuntu ถึงบอกว่าเป็น 6.00 ทั้งคู่ แต่ไม่ใช่เรื่องปกติทั่วไป
ถ้าเป็นเครื่องส่วนตัว ดิสโทรแบบ rolling release อย่าง Arch หรือ Manjaro จะตามเวอร์ชัน upstream ได้สม่ำเสมอกว่า แต่ภาระดูแลรักษาและความคาดหวังว่าต้องจัดการเองก็สูงขึ้น
สิ่งที่น่าหงุดหงิดกว่าในเรื่องการจัดการเวอร์ชันของ Linux/โอเพนซอร์สคือไลบรารีต่าง ๆ มักเลื่อนการประกาศ v1.00 นานเกินไป
ทั้งที่ฝังอยู่ในอีโคซิสเต็มอย่างแพร่หลาย เสถียร และฟีเจอร์ก็แทบครบแล้ว แต่ยังค้างอยู่ที่ v0.2 หรือ v0.68 เป็นปี ๆ ทำให้ผู้เริ่มต้นสับสน
Debian มีรอบรีลีสยาว แต่เสถียรมาก และใน stable ทุกอย่างทำงานเข้ากันได้ดี
โดยพื้นฐานแล้ว Ubuntu ให้ความรู้สึกเหมือน Debian ที่เติมคำถามว่า “ถ้ารีลีสบ่อยขึ้นล่ะ?” เข้าไป
ถ้าต้องการเครื่องมือล่าสุด ก็ต้องยอมรับตัวเลือกที่อาจเสถียรน้อยกว่าอย่าง Nix หรือ Arch ซึ่งทั้งคู่ก็ไม่ได้เป็นมิตรนัก
ถ้าต้องการทั้งความเสถียรและเครื่องมือล่าสุด Gentoo เป็นทางหนึ่ง แต่ก็หนักกว่า Arch เสียอีก
ถ้าต้องการความเสถียรและความเรียบง่าย ก็สามารถยอมแลกพื้นที่ดิสก์เพื่อใช้แนวทางอย่าง Docker/podman, flatpak, appcontainers, snap ได้
Windows และ Mac ก็มีปัญหาแบบเดียวกัน และ Windows แก้ปัญหามาโดยการพกไลบรารีเก่า ๆ ไปด้วย แล้วทำ dynamic linking ตามแอปที่กำลังรัน
unzipเป็น กรณีพิเศษการพัฒนา upstream แทบหยุดไปแล้ว และรีลีสล่าสุดคือ 6.0 ในปี 2009
หลังจากนั้นพบปัญหาหลายอย่างและฟีเจอร์ก็เริ่มไม่พอ แต่ละดิสโทรจึงโปะแพตช์จำนวนมากทับรีลีสนั้น ส่งผลให้เกิดไฟล์ปฏิบัติการที่ต่างกันมากทั้งที่มีหมายเลขเวอร์ชันเดียวกัน
[0]: https://infozip.sourceforge.net/UnZip.html
[1]: ถ้าดูสูตรบิลด์ของ Arch จะเห็นจำนวนแพตช์ที่ถูกใช้: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
การทำงานร่วมกันได้ในระดับหนึ่งเป็นเรื่องดี แต่การมีตัวเลือกหลากหลายก็เป็นข้อดีเช่นกัน
ในคลังแพ็กเกจของดิสโทรส่วนใหญ่มี bsdtar อยู่ จึงน่าลองใช้แทน และชื่อแพ็กเกจอาจเป็น libarchive แล้วแต่ดิสโทร
ใช้แค่
bsdtar xf path/to/fileก็แตกไฟล์ได้เกือบทุกรูปแบบ และรองรับ AES ของ ZIP ด้วยmacOS มีมาให้โดยค่าเริ่มต้น และ Windows ก็น่าจะมีรวมอยู่ด้วย
สำหรับงานแต่ละอย่าง ให้สร้าง git repository และ
flake.nixแล้วให้ direnv เปิดใช้สภาพแวดล้อมที่ประกาศไว้ใน flake เมื่อเข้าไปในไดเรกทอรีนั้นถ้าเขียนสคริปต์ที่ใช้
grepก็เอาสคริปต์เข้า repository และเพิ่มpkgs.gnugrepลงในflake.nixด้วยทำแบบนี้แล้วจะใช้เวอร์ชันที่ประกาศไว้ ไม่ใช่เวอร์ชันของระบบ และแม้ย้ายจาก macOS ไป Linux หรือ WSL ก็จะเรียก grep เวอร์ชันเดียวกัน
Nix มักถูกมองว่าไม่เป็นมิตรกับมือใหม่ จึงไม่กล้าแนะนำตรง ๆ แต่ใจความคือควรประกาศ dependency ด้วยวิธีใดวิธีหนึ่ง และใช้เฉพาะ dependency ที่ประกาศไว้เท่านั้น
Docker ก็ทำได้ และอีโคซิสเต็มภาษาอย่าง Python/Node.js/Go/Rust ก็มีวิธีบันเดิลและเรียกใช้ dependency เช่นกัน
วิธีนี้ทำให้การอัปเดต dependency เหลือร่องรอยเป็น commit และเมื่อมีอะไรพัง ก็ย้อนกลับไป commit ก่อนหน้าได้
repository แบบนี้ไม่จำเป็นต้องเป็นโปรเจกต์ซอฟต์แวร์เสมอไป จะเป็น “ชุดเครื่องมือที่ต้องใช้เมื่อทำ XYZ” ก็ได้
การที่ openrsync ไม่รองรับฟีเจอร์บางส่วนของ rsync นั้นน่ารำคาญอยู่บ้าง
แต่ก็เป็นเรื่องดีที่ตอนนี้มี การนำ rsync ไปใช้งานแบบอิสระ หลายตัวแล้ว
เพราะนั่นหมายความว่า rsync ไม่ได้ถูกมองเป็นแค่ซอฟต์แวร์ธรรมดา แต่ถูกปฏิบัติเหมือนเป็น โปรโตคอล จริง ๆ
ถ้าเข้าใกล้ความเป็นโปรโตคอลมากขึ้น ก็น่าจะมีจุดที่เป็น API สำหรับความต่างแบบไบนารี บนพื้นฐานอัลกอริทึมของ rsync ออกมาได้
ข้อเท็จจริงที่น่าสนใจคือ Dropbox เคยใช้ความต่างแบบไบนารีของ rsync ภายใน เพื่ออัปโหลดการเปลี่ยนแปลงเล็ก ๆ ในไฟล์ขนาดใหญ่ได้อย่างรวดเร็ว
ผมคิดว่าตอนนี้ก็น่าจะยังทำอยู่ แต่ใน API endpoint สาธารณะไม่มีฟีเจอร์นี้ ดังนั้นแม้ไฟล์ขนาดใหญ่จะมีการเปลี่ยนแปลงเพียงเล็กน้อย ก็ต้องอัปโหลดทั้งไฟล์ใหม่
มีประโยชน์ทีเดียวในสภาพแวดล้อมองค์กรที่ SSH+rsync ถูกบล็อก แต่อนุญาตให้สร้างบริการ gRPC ได้
rsync มีฟีเจอร์เยอะ จึงเลี่ยงไม่ได้ที่จะต้องใช้เวลาค่อนข้างมาก
ในแพตช์ mainline ของ rsync มีการเพิ่มการรองรับ extended attributes เพื่อรองรับ metadata ของ macOS
“Carbon Copy Cloner” ของ Bombich เป็นแอป GUI ที่ครอบสิ่งนี้ไว้
https://support.bombich.com/hc/en-us/articles/20686446501143...
Mike Bombich เป็นที่รู้จักจากโพสต์ในกระดานผู้ดูแลระบบ macOS Server และมีเอกสารที่เกี่ยวข้องด้วย
https://web.archive.org/web/20140707182312/http://static.afp...
Nathaniel Gray สร้าง Backup Bouncer ซึ่งตรวจสอบความถูกต้องครบถ้วนของแบ็กอัป รวมถึงหลายสตรีม, extended attributes, ACL และอื่น ๆ
https://github.com/n8gray/Backup-Bouncer
ยังมี RsyncX ซึ่งเป็นแอป SwiftUI ที่ครอบ rsync อีกด้วย
https://github.com/rsyncOSX/RsyncOSX
ในยุคที่รันซอฟต์แวร์ macOS “Classic” บนระบบ UNIX ใหม่ ๆ เรื่องเหล่านี้เคยถูกให้ความสำคัญมากจริง ๆ
https://web.archive.org/web/20161022012615/http://blog.plast...
IFileOperation (Windows) และ FileManager (macOS) จะทำการคัดลอกที่มีประสิทธิภาพดีที่สุดตามที่ระบบไฟล์ underlying รองรับ
บน SMB และ ReFS การตรวจ CRC เป็นแค่ระดับ checkbox และบน SMB share สมัยใหม่ของ Windows Server รุ่นใหม่ ขั้นตอนจับคู่เนื้อหาของ rsync เป็นงานซ้ำซ้อน
ระหว่าง Windows ด้วยกัน IFileOperation มี throughput เร็วกว่า rsync 1.5–8 เท่า และใช้ CPU ต่ำกว่า อีกทั้งอาจเร็วกว่าการคัดลอกไฟล์ทั่วไปด้วย Go 1.2–3 เท่าด้วย
ถ้ามองแค่ Linux โดยไม่สนใจระบบปฏิบัติการที่ใช้ metadata ของระบบไฟล์ซับซ้อนจริง ๆ openrsync หรือโปรแกรมที่เรียบง่ายกว่านั้นก็เพียงพอแล้ว
สงสัยว่ามีเอกสารที่อธิบายได้ดีไหมว่าทำไม Apple ถึงกลัว GPLv3 ขนาดนั้น
ถ้าคอมไพล์ไฟล์ executable แบบ static ก็น่าจะไม่มีปัญหาไม่ใช่หรือ
ตอนนั้น TiVo ทำแบบนั้น จึงถูกเรียกว่า ทิโวอิเซชัน
สำหรับ iOS เหตุผลที่ไม่ใช้ GPLv3 นั้นชัดเจน เพราะจะละเมิดเงื่อนไข
macOS อาจใส่โค้ด GPLv3 ได้ แต่ Apple แชร์โค้ดจำนวนมากระหว่าง iOS/macOS/watchOS/tvOS/visionOS ดังนั้นการมีฐาน GPLv3 แค่ในระบบปฏิบัติการเดียวแต่ไม่ใช้ในที่เหลือจึงแทบไม่มีความหมาย
ไม่ใช้เลยจะง่ายกว่า
อีกทั้งถ้าในอนาคต macOS ล็อกการรันโค้ดของผู้ใช้ให้แน่นขึ้น ก็ไม่ต้องกังวลว่าจะต้องรื้อโค้ด GPLv3 ออกในตอนนั้น
สิ่งที่เคยคิดว่าปลอดภัยเต็มที่ ในมุมของทนายก็ไม่ได้ฟันธงได้ขนาดนั้น
ผมไม่รู้เหตุผลของ Apple แต่ทนายบริษัทของบริษัทอื่น ๆ ให้หลักการว่า หากเป็นไปได้ให้เลือก ไลเซนส์ที่ไม่ใช่ GPL
ดูจากประวัติคดีเกี่ยวกับ GPLv2 แล้ว สิ่งที่ได้ดูน้อยเมื่อเทียบกับแรงที่ต้องลงไป
จากมุมของ Apple ถ้าแค่แทนที่ส่วนที่ดูเป็น “ปัญหา” ก็หลีกเลี่ยงหมวดปัญหาทั้งหมดได้
ประเด็นทางเทคนิคปลีกย่อยอาจน่าสนใจ แต่ผมมองว่าไม่ใช่แก่นหลัก
ควรอย่าเชื่อคำอธิบายของคนอื่นเกี่ยวกับเจตนาของ Apple
ตอนที่ผมเขียนอิมพลีเมนเทชัน https://github.com/gokrazy/rsync ด้วย Go เอง ได้ดู openrsync แล้วพบว่าโค้ดดี
แต่เสียดายที่ openrsync ไม่ได้ เข้ากันได้กับ rsync 100%
พอเทสต์ของผมพังบน macOS 15 เลยรู้ว่า Apple เริ่มเปลี่ยนไปใช้ openrsync แล้ว
เห็นว่า openrsync ถูกเขียนขึ้นเป็นส่วนหนึ่งของโปรเจกต์ rpki-client(1) ซึ่งเป็นตัวตรวจสอบ RPKI สำหรับ OpenBSD และได้รับทุนจาก NetNod, IIS.SE, SUNET, 6connect ก็เลยสงสัยว่าองค์กรเหล่านี้ให้ทุนกับการพัฒนานี้ไปทำไม
https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...
https://news.ycombinator.com/item?id=43605846
บริษัทต่าง ๆ ให้ทุนกับสิ่งที่มีประโยชน์หรือจำเป็น
บางบริษัทในรายชื่ออาจใช้ BSD อยู่ และอาจต้องการหรือจำเป็นต้องมี อิมพลีเมนเทชัน rsync ที่ไม่ใช่ GPLv3
หรืออาจแค่มีความสนใจที่จะสนับสนุนโปรเจกต์โอเพนซอร์สและการพัฒนาก็ได้
ช่วงหนึ่งจนถึง Sequoia 15.3 ยังสามารถใช้ได้ทั้ง rsync_samba และ rsync_openrsync ผ่าน
/var/select/rsyncหรือ environment variableCHOSEN_RSYNCจุดที่น่ารำคาญเป็นพิเศษของ openrsync คือมันอ้างว่ารองรับองค์ประกอบพาธแบบเมจิก
/./สำหรับ--relativeผมส่งรายงานบั๊กเรื่องนี้ให้ Apple ไปเมื่อประมาณหนึ่งเดือนก่อน
ตั้งแต่ Sequoia 15.4 เป็นต้นมา rsync_samba หายไปแล้ว และผมติดตั้ง rsync ไว้ผ่าน Homebrew
เมื่อไม่นานมานี้เจอปัญหานี้ โดยเมื่อสร้าง iOS
.ipaด้วยxcodebuildจาก command line ดูเหมือนภายในจะเรียก rsync เพื่อคัดลอกไฟล์ระหว่างไดเรกทอรีภายในเครื่องแต่ Homebrew rsync อยู่ก่อนใน
$PATHจึงไปรันตัวนั้น และxcodebuildส่งอาร์กิวเมนต์เฉพาะของ openrsync คือ--extended-attributesไปให้Homebrew rsync ไม่เข้าใจอาร์กิวเมนต์นั้นจึงล้มเหลวและออกจากโปรแกรม
ยังดีใจอยู่ที่ Apple ไม่ได้ค่อย ๆ ตัด ด้าน POSIX ออกเพื่อทำให้ osx เหมือน iOS แต่ยังคงปรับปรุงและยอมรับมันต่อไป