2026 年、リモート Mac から Linux Runner へ成果物を rsync/SFTP 同期するときの .DS_Store・.AppleDouble・._* リソースフォーク:--delete 半径と除外テンプレの意思決定マトリクス
ビルドの真実の源をリモート Mac に置くチームは、転送が成功しても Linux 側に ._ が増えるとネットワークを疑いがちです。原因は多くの場合、メタデータの書き込み面と削除半径が変更票に載っていないことです。本稿では脅威モデルを整理し、除外テンプレ、staging 限定の --delete、読み取り専用リリースアンカー、SHA256 もしくは manifest ゲートの順序を示します。併読として《APFS xattr》《files-from》《原子リリース》《隔離属性》を推奨します。
2026 年も小さなファイルがインシデントに値する理由
一:リソースフォークは Linux 上で ._* と .AppleDouble として可視化され、署名や静的解析の入力に混ざります。
二:.DS_Store はディレクトリ差分を揺らし、容量計画とアラート閾値を歪めます。
三:--delete は「掃除」と衝突し、誤って本物の成果物を消します。
四:APFS の xattr 整合性問題と混ぜると、当番は権限・xattr・Finder ノイズの間を往復します。
五と六:対話型 SFTP と CI が同一書き込み鍵を共有すると、ドラッグ由来のノイズを説明できません。大物バイナリだけをハッシュしディレクトリ項目を無視すると公証段階で破綻します。
- Finder メタデータと成果物を別サブツリーに分離し、リリースアンカーへの手動ドロップを禁止します。
--deleteを使うジョブは staging パス定数に紐付け、二名レビューを必須化します。
マトリクス:除外・manifest・読み取り専用アンカー
目的は削除半径と書き込み面の縮小です。小規模チームは除外と staging から始め、複雑なツリーは files-from、外向きの不変性はアンカーとシンボリックリンクで担保します。
| 戦略 | 適合 | 誤用 | 関連記事 |
|---|---|---|---|
| 除外テンプレ | 安定ツリー | delete と併用ミス | bwlimit 記事 |
| manifest | 複雑ツリー | 生成器が不安定 | files-from |
| 読み取り専用アンカー | 人と CI の分離 | 鍵が広すぎる | 原子 |
| xattr | タグ ACL 保持 | ノイズと混同 | xattr |
How-to:六ステップ
ホストとパスは置き換えてください。併発セッション予算は別記事と合わせて読んでください。
rsync -az \\
--exclude='.DS_Store' \\
--exclude='.AppleDouble' \\
--exclude='._*' \\
--delete \\
./staging/out/ user@runner:/data/in/
- パス定数:リリースアンカー、staging、Runner を単一設定へ。
- delete 面:staging のみ。push と pull でテンプレを分離。
- 除外:IDE キャッシュも列挙。
- dry-run:三回、削除と転送件数を比較。
- アカウント:人間は書き込み可ツリー、CI は読み取り専用アンカーのみ。
- ゲート:合格後に可視性を切替。
SFTP のみの経路では rsync フィルタより監査粒度が弱くなりがちなので、アンカーと manifest を厚くします。
変更票に書く四要素
テンプレ版、._* と .DS_Store 件数、delete スコープ宣言、ゲート要約(manifest digest か成果物ハッシュと失敗サンプルパス)を毎回残します。数値は環境依存ですが、フィールドの有無は共通です。
サーバ側の三層
協作、ビルド作業、リリースアンカーを分け、CI は読み取り専用アンカーのみマウントします。sshd Match や監査ログは専門記事へ委譲し、ここでは書き込み分離を最優先します。
隔離属性とコード署名は別次元です。隔離の記事を併読し、展開成功をインストール成功と混同しないでください。
サイト内の読み順
除外テンプレ → files-from → APFS xattr → 原子リリース。オブジェクト二段階は該当記事を参照してください。
FAQ
超長い exclude 一行? 短期は可。版管理し、件数監視で manifest 昇格を判断します。
Linux で ._ を消しても復活? ソースが生成し続けています。クライアントとマウント設定を直してください。
tar と rsync? 異種 OS で権限とフォークが重要なら tar が安定しやすいです。xattr 記事の表を参照してください。
まとめとマネージド Mac の位置づけ
本稿は .DS_Store、.AppleDouble、._* を削除半径とゲート信頼性を左右する制御変数として位置づけました。自前ノードは権限行列と当番ドキュメントに継続コストがかかります。
ゲートを置き換えるものではありませんが、人間と自動化が同じ可変ツリーに書き込む確率を下げるのに、リモート Mac をレンタルでホスト化するのは有効です。夜間のノイズ調査より機能開発へ時間を戻せます。
料金とプランおよびヘルプを参照し、SFTP のように境界を制御できる長期ノードとしてご検討ください。