- macOSに組み込まれているファイル同期ツールが2006年ベースのまま据え置かれていた状況で、Appleは rsync 2.6.9 を openrsync に置き換えた
- 従来のmacOSのrsyncは、セキュリティやその他の問題に必要な修正は受けていたが、2.6.9以降の rsync 3.xの機能 は含まれていなかった
- 移行の主な背景はライセンスの違いで、rsync 2.xは GPLv2、rsync 3.xは GPLv3 の下で配布されている
- openrsyncはrsyncと互換性があるが、コマンドライン引数の一部のみ をサポートするため、既存のスクリプトがSequoiaでそのまま動作しない可能性がある
- macOS 15.4時点では
/usr/bin/rsync がopenrsyncにリンクされており、Mac管理者は対応オプションと既存自動化の 互換性 を確認する必要がある
macOSに長く残っていたrsync 2.6.9
- rsync はUnix系オペレーティングシステムでファイルを転送・同期するためのコマンドラインツール
- 同じコンピュータに直接接続されたストレージ間で使える
- ネットワーク上の別のコンピュータとファイルを同期する用途にも使える
- macOSには長年rsyncが含まれていたが、Appleが提供していたバージョンは rsync 2.xの最終版 であるrsync 2.6.9だった
- rsync 2.6.9 は2006年11月に公開され、その後rsync 3.xが登場しても、AppleはmacOSのrsyncをそれ以降のバージョンへ更新しなかった
- AppleはmacOSに含まれるrsync 2.6.9に対して、セキュリティ問題やその他の問題に必要な更新は行ってきた
- しかしmacOS Sequoiaまで、Appleのrsyncはほぼ 20年前の基盤 のままで、2.6.9以降のrsyncで追加された新機能は含まれていなかった
GPLv2とGPLv3が生んだバージョン停滞
- rsync 2.xと3.xは、それぞれ異なる GPLライセンスのバージョン の下で配布されている
- 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 はGPLライセンスを採用しないrsync実装
- openrsyncはBSD系ライセンスの1つである ISC license で配布されている
- ISC licenseはパーミッシブライセンスで、対象ソフトウェアの使用・改変・配布に最小限の制限しか設けない
- Appleは、rsync 3.xのGPLv3条件とは異なり、openrsyncのライセンス条件には準拠できると判断した
Mac管理者に重要な互換性の違い
- Appleは今後、rsyncの GPL準拠問題 を気にせずopenrsyncの更新版を提供できる
- より大きな実務上の変化は、openrsyncがrsyncと互換性を持ちながらも、rsyncのコマンドライン引数の一部のみを許可 している点にある
- 既存のmacOSで動作していたrsync機能が、macOS Sequoiaでは失敗する可能性がある
- その機能が、Sequoiaに含まれるopenrsyncのコマンドラインツールに存在しない可能性があるため
- macOS Sequoiaのopenrsyncでサポートされる機能は、openrsyncのマニュアルページ で確認できる
macOS 15.4で確認する方法
- macOS 15.4時点では openrsync ツールは
/usr/bin/rsync にリンクされている
- ユーザーは従来どおりrsyncコマンドラインツールを実行する感覚でopenrsyncを使える
- 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 を置き換えられるという信頼感が持てない
ファイルコピー用プログラムなら、元データとメタデータを 1 ビットも失わない完全なコピーができるべきであり、そうでなければ使い物にならないレベルだと考える
Unix 系の多くのコピー／アーカイブツールは、デフォルトオプションでは完全なコピーができず、どのオプションを使っても不可能なツールもある
scp も少なくとも数年前までは、OS やファイルシステムが異なる場合に完全なコピーが難しかったため使わず、ssh 上で rsync だけを使ってきた
rsync は適切なオプションを指定すれば、FreeBSD UFS と Linux XFS の間のように、異なる OS／ファイルシステム間でも拡張属性、ACL、高精度タイムスタンプまで保持できる珍しいツールである
openrsync のドキュメントはこうした完全コピーを保証していないため、現時点ではできないものと仮定し、役に立たないと判断している
アーカイブに関しては、Linux では bsdtar が pax 形式を使うと、ほぼ完全なファイルコピーを保存できる一方、古い tar/cpio 形式では現代的なメタデータを格納できない
普段 rsync は
/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"として alias しているcoreutils の
cpも、正しい CLI オプションとコンパイルオプションなら完全コピーが可能だが、一部のディストリビューションは拡張属性サポートなしでビルドしているため、警告やエラーなしに部分コピーしかしない私たちは非常に慎重にすべてを復元しているが、時々それを気にしているのは自分たちだけのように感じる
基本的に openrsync は、ライセンス上の制約が少ない rsync だと考え、動作が違うとは見なさないのではないかと思う
openrsync の README には rsync と互換性があると書かれており、rsync のドキュメントを見るようにとも書かれている
拡張属性、ACL、高解像度タイムスタンプがプロトコルレベルでのオプション機能でないなら、互換性を主張するには現代の rsync がサポートしているものをすべてサポートすべきではないかと思う
そうでなければ、プロトコル全体を受け入れつつ ACL のようなものを単に捨てるという意味なのか気になる
ただし公式 Web サイトにも “We are still working on it... so please wait.” と書かれている
そういうユーザーは単に rsync をインストールすればよい
alias で使っている
--xattrs、--acls、--hard-linksがすべて抜けている[0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...
比較的新しい Linux ユーザーとしては、バンドルされているシステムユーティリティのバージョン管理がかなり混沌としているように感じる
代表例が
unzipで、Debian サーバーや古い Ubuntu サーバーに同梱されているunzipは AES-256 で暗号化された ZIP を扱えなかったが、Stack Overflow を見ると、いくつかのディストリビューションではそれに対応するよう更新されているようだった問題は、更新された
unzipを簡単には見つけられず、どれも「version 6.00」だと主張するのに実際の挙動は異なり、見つけたとしてもシステム同梱版を置き換えて安全なのか分からないことだ結局、誰かが広く使われているユーティリティに良い機能を追加しても依然として使えず、コアなシステムユーティリティであるがゆえに、むしろサードパーティ製ツールより更新が難しくなっているように感じる
Windows や macOS もシステムユーティリティに関しては同じか、それ以上に悪いかもしれないが、Linux はこういうことをもっと上手く扱えると思っていた
unzipの代わりに 7z を使うのがよいLinux で ZIP や圧縮ファイル全般を扱うときに
unzipを使った記憶はほとんどないUnix 哲学に従うなら、tar でまとめ、gzip で圧縮し、pgp で暗号化するというように、1つのことをうまくこなす単純なツールをパイプでつなぐ流れも自然だ
バージョンについては、Debian/Ubuntu がどちらも 6.00 としている理由ははっきりしないが、一般的なことではない
個人用マシンなら Arch や Manjaro のようなローリングリリースのディストリビューションのほうがアップストリーム版により継続的についていくが、保守の負担と自分で管理することへの期待値は大きくなる
Linux/オープンソースのバージョン管理でさらに不便なのは、ライブラリが v1.00 の宣言を過度に先延ばしにすることだ
エコシステムに広く組み込まれ、安定していて機能もほぼ完成しているのに、v0.2 や v0.68 のまま何年も留まり、初心者を混乱させる
Debian はリリース周期が長いが非常に安定しており、stable ではすべてがうまく噛み合って動く
Ubuntu は基本的に Debian に「もっと頻繁にリリースしたらどうか？」を加えたようなものだ
最新のツールが欲しいなら Nix や Arch のように、安定性がやや低いかもしれない選択肢を受け入れる必要があるが、どちらもあまり親切ではない
安定性と最新ツールの両方が欲しいなら Gentoo という方法もあるが、Arch よりさらに負担が大きい
安定性と単純さを望むなら、ディスク容量を犠牲にして Docker/podman、flatpak、appcontainers、snap のような方式を使うこともできる
Windows と Mac にも同じ問題があり、Windows は古いライブラリを同梱し、実行中のアプリに応じて動的リンクする方式で解決してきた
unzipは特殊なケースだアップストリーム開発は事実上止まっており、最後のリリースは 2009 年の 6.0 だ
その後、複数の問題が見つかり機能も不足するようになったため、各ディストリビューションがそのリリースに大量のパッチを重ねた結果、同じバージョン番号を持つ非常に異なる実行ファイルが生まれた
[0]: https://infozip.sourceforge.net/UnZip.html
[1]: Arch のビルドレシピを見ると、適用されるパッチ数が分かる: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
ある程度の相互運用性は望ましいが、多様な選択肢があることも利点だ
ほとんどのディストリビューションのリポジトリには bsdtar があるので、代わりに試す価値があり、ディストリビューションによってはパッケージ名が libarchive の場合もある
bsdtar xf path/to/fileだけでほぼすべての形式を展開でき、ZIP の AES にも対応しているmacOS には標準で含まれており、Windows にもおそらく含まれているはずだ
何かをするたびに git リポジトリと
flake.nixを作り、direnv がそのディレクトリに入ったときに flake で宣言された環境を有効化するようにするgrepを使うスクリプトを書くなら、そのスクリプトをリポジトリに入れ、pkgs.gnugrepもflake.nixに追加するこうすればシステムのバージョンではなく宣言されたバージョンが使われ、macOS から Linux や WSL に移っても同じバージョンの grep を呼び出すことになる
Nix は初心者に不親切だという評判が多く、そのまま勧めるのは慎重になるが、要点は何らかの方法で依存関係を宣言し、宣言された依存関係だけを使うことだ
Docker でも可能で、Python/Node.js/Go/Rust などの言語エコシステムも依存関係をまとめて呼び出す方法を提供している
こうすれば依存関係の更新がコミットとして残るため、何かが壊れたときに以前のコミットへ戻れる
こうしたリポジトリは必ずしもソフトウェアプロジェクトである必要はなく、「XYZ をするときに必要なツール集」でもよい
openrsync が rsync の一部機能をサポートしていないのは少し厄介
それでも、今では rsync の独立実装が複数生まれているのは良いこと
rsync が単なるソフトウェアではなく、実質的に プロトコルのように扱われているという意味だから
プロトコルに近づけば、rsync アルゴリズムベースの バイナリ差分 API のようなものも出てくるかもしれない
面白いことに、Dropbox は内部で rsync のバイナリ差分を使い、大きなファイルの小さな変更を高速にアップロードしていた
今もそうだと思うが、公開 API エンドポイントにはこの機能がないため、大きなファイルに小さな変更だけがあってもファイル全体を再アップロードする必要がある
企業環境で SSH+rsync はブロックされているが、gRPC サービスの構築は許可されている場合にはかなり有用
rsync は機能が多いので、かなり時間がかかるのは仕方ない
メインラインの rsync パッチでは、macOS メタデータ対応のために 拡張属性サポートが追加された
Bombich の “Carbon Copy Cloner” はこれをラップした 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 は、マルチストリーム、拡張属性、ACL などを含めてバックアップの忠実度を検証する Backup Bouncer を作った
https://github.com/n8gray/Backup-Bouncer
rsync をラップした SwiftUI アプリ RsyncX もある
https://github.com/rsyncOSX/RsyncOSX
新しい UNIX システム上で “Classic” macOS ソフトウェアを動かしていた時代には、こうしたものが本当に重要視されていた
https://web.archive.org/web/20161022012615/http://blog.plast...
IFileOperation（Windows）と FileManager（macOS）は、基盤となるファイルシステムがサポートする最も高性能なコピーを実行する
SMB と ReFS では CRC 検査はチェックボックス程度の機能であり、現代の Windows Server 上の現代的な SMB 共有では、rsync の内容マッチング段階は重複作業になる
Windows 同士では IFileOperation は rsync よりスループットが 1.5〜8 倍速く、CPU 使用量も低く、一般的な Go のファイルコピーよりも 1.2〜3 倍速いことがある
複雑なファイルシステムメタデータを実際に使う OS を気にせず Linux だけを見るなら、openrsync やもっと単純なプログラムで十分
Apple がなぜ GPLv3 をそこまで恐れるのか、うまく説明した資料があるのか気になる
実行ファイルを静的にコンパイルすれば問題にならないはずでは、と思う
当時 TiVo がそうしていたため Tivoization と呼ばれた
iOS で GPLv3 を使わない理由は明確で、条件に違反することになるから
macOS には GPLv3 コードを載せることはできるだろうが、Apple は iOS/macOS/watchOS/tvOS/visionOS 間で多くのコードを共有しているため、1つの OS だけを GPLv3 ベースにして他では使わないのはあまり意味がない
まったく使わないほうが単純
また将来 macOS でユーザーコードの実行をさらにロックダウンしても、その時に GPLv3 コードを取り除く心配をしなくて済む
完全に安全だと思っていたものも、弁護士の立場ではそこまで断定的ではなかった
Apple の理由は分からないが、他社の企業弁護士たちは可能なら 非 GPL ライセンスを選ぶという原則を示していた
GPLv2 関連の判例の履歴を見ると、かける労力に比べて得るものが少ないように見える
Apple の立場で「問題」に見える部分を単に置き換えれば、その問題領域全体を避けられる
細かな技術的論点は興味深いかもしれないが、核心ではないと思う
Apple の意図についての他人の説明は信じないほうがいい
自分で https://github.com/gokrazy/rsync の実装を Go で書いていたときに openrsync を見たが、コードは良かった。
ただし openrsync が rsync と 100% 互換ではないのは残念。
macOS 15 で自分のテストが壊れたことで、Apple が openrsync への移行を始めたことを知った。
openrsync は OpenBSD 向けの RPKI 検証ツールである rpki-client(1) プロジェクトの一部として書かれ、NetNod、IIS.SE、SUNET、6connect が資金提供したとされているが、これらの組織がなぜこの開発に資金を出したのか気になる。
https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...
https://news.ycombinator.com/item?id=43605846
企業は有用なもの、あるいは必要なものに資金を出す。
リストにある企業の一部は BSD を使っている可能性があり、GPLv3 ではない rsync 実装を望んでいた、または必要としていた可能性がある。
あるいは単に、オープンソースプロジェクトと開発を支援したいという関心があっただけかもしれない。
しばらくの間、Sequoia 15.3 までは
/var/select/rsyncや環境変数CHOSEN_RSYNCを通じて、rsync_samba と rsync_openrsync の両方を利用できた。openrsync で特に腹立たしい点は、
--relative用の/./マジックパス要素をサポートしていると主張していたことだ。この問題について、1か月ほど前に Apple にバグレポートを送った。
Sequoia 15.4 以降は rsync_samba がなくなり、rsync は Homebrew でインストールしておいた。
最近この問題に遭遇した。コマンドラインで
xcodebuildを使って iOS の.ipaを作ると、内部で rsync を呼び出してローカルディレクトリ間でファイルをコピーしているようだ。ところが
$PATHでは Homebrew の rsync が先に来ていたためそれが実行され、xcodebuildは openrsync 専用の引数--extended-attributesを渡していた。Homebrew の rsync はその引数を理解できず、失敗して終了した。
Apple が macOS を iOS のようにしようとして POSIX 面を徐々に取り除くのではなく、引き続き改善し受け入れている点は、今でも喜ばしい。