2026 Mac distant : DS_Store, AppleDouble et fourches rsync/SFTP pour CI

Versionnez les exclusions, limitez delete au staging, séparez les comptes, exécutez les barrières avant la visibilité ; liens vers xattr APFS, files-from et publication atomique.

Trois douleurs numérotées

1. Les fourches apparaissent comme ._* sur Linux et polluent la signature.
2. .DS_Store fausse les deltas de répertoire et les alertes.
3. --delete sans staging supprime de vrais artefacts lorsque les pairs manquent.

Beaucoup d’équipes dressent un Mac distant comme source de vérité des builds, puis imputent la latence réseau lorsque des ._* ou des .DS_Store envahissent les runners Linux. La cause est rarement « le lien » : il manque le plus souvent des surfaces d’écriture disjointes, des gabarits d’exclusion suivis en contrôle de source, et un périmètre --delete limité à un sous-arbre de staging explicitement nommé dans le ticket de changement.

Les fourches AppleDouble se matérialisent hors APFS comme des ._* et se glissent dans la signature ou les scanners lorsque l’inventaire reste flou. .DS_Store fausse les deltas de répertoire même avec une politique bureau stricte, et rsync --delete sans invariant de staging confond « ménage » et suppression réelle. Traitez la conservation des xattr APFS dans un fil séparé du bruit Finder : mélanger ACL, -aE et simples exclusions dans le même runbook recycle les incidents sans progrès mesurable.

Réutiliser les mêmes identifiants pour SFTP interactif et pour la CI rend l’audit illisible dès qu’un glisser-déposer réintroduit des métadonnées. Se limiter à des empreintes sur de gros bundles sans recouper l’arborescence laisse passer des fourches qui cassent la chaîne plus tard. Pour l’astreinte, associez dans les journaux structurés la version du gabarit d’exclusion, l’identifiant de build, le sous-arbre staging et la révision de manifeste afin de répondre en quelques minutes.

Les revues d’incident retrouvent trois profils : équipes mobiles synchronisant d’immenses arborescences type DerivedData, équipes contenu mélangeant assets et artefacts sur un seul volume, plateformes jonglant entre variantes rsync différentes sur macOS et Linux. La planification capacitaire doit suivre le churn d’inœuds et d’entrées de répertoire, pas seulement le débit en octets ; des transferts « verts » peuvent masquer une prolifération de petits fichiers qui fera échouer une étape aval.

Pour réduire la dérive : test négatif qui place volontairement un .DS_Store près de l’ancre de publication, trois dry-runs dont les agrégats rejoignent le manifeste, gabarits push et pull distincts pour ne pas inverser la sémantique delete, et couches côté serveur (collaboration humaine, espace builder, ancre en lecture seule pour la CI). Consignez dans le même ticket version de gabarit, compteurs de bruit, portée de suppression et digest de manifeste avant d’investir dans un nouvel orchestrateur. Les cas NFS, caches d’IDE et clauses contractuelles sont détaillés dans la section suivante.

Approfondissement et cas limites

Les pipelines nocturnes et les transferts manuels partagés multiplient les verrous implicites. Verrouillez des créneaux où seule l’automatisation écrit, puis rouvrez la surface humaine après bascule de visibilité pour éviter les courses sur les métadonnées.

Les bundles Xcode exportés avec des chemins relatifs masquent encore des attributs étendus. Ajoutez une étape qui liste les xattr sur un échantillon de binaires avant envoi, sans confondre ce contrôle avec un simple filtre ._*.

Les montages NFS hérités conservent parfois des fichiers cachés côté serveur. Documentez le protocole exact (NFSv4 ACL, mode squash) dans le même ticket que les exclusions, sinon les audits croisent des chemins incomparables.

Les caches Gradle ou npm copiés depuis le Mac peuvent charrier des milliers de petits fichiers. Isolez-les dans un volume dédié ou excluez-les explicitement ; sinon les budgets inode explosent avant même la signature.

Pour les artefacts graphiques, imposez une convention de nommage et une taille maximale par lot. Les glisser-déposer massifs contournent souvent le hook Git LFS et réintroduisent du Finder bruit.

Les journaux applicatifs devraient inclure un identifiant de politique d’exclusion, pas seulement la version d’outil. Cela permet de corréler un saut de compteur avec un merge précis du dépôt de templates.

Les reprises après incident gagnent à distinguer « explosion de métadonnées » et « suppression réelle ». Préparez deux scripts de diagnostic : l’un compte les ._*, l’autre compare l’inventaire manifeste fichier par fichier.

Les clauses contractuelles doivent préciser qui calcule l’empreinte d’arborescence et à quelle profondeur. Un fournisseur qui ne hash que les feuilles et un client qui attend la racine complète resteront en désaccord malgré des pipelines verts.

Contrôle rapide : le ticket mentionne-t-il trois agrégats (ajouts, modifications, suppressions) alignés sur le dernier dry-run ? Si la réponse est non, ajoutez le log structuré avant d’investir dans un nouvel orchestrateur.

How-to en six étapes

rsync -az \
  --exclude='.DS_Store' \
  --exclude='.AppleDouble' \
  --exclude='._*' \
  --delete \
  ./staging/out/ user@runner:/data/in/

1. Figez les constantes de chemins pour ancre, staging et runner.
2. Activez delete uniquement sur le sous-arbre staging.
3. Baseline d’exclusion pour .DS_Store, .AppleDouble, ._* et caches IDE.
4. Trois dry-runs : suppressions et transferts vs manifeste.
5. Séparez comptes SFTP interactifs et CI lecture seule.
6. Barrière checksum ou manifeste avant bascule de visibilité.

Matrix

Conclusion

Exclusions versionnées, delete limité au staging, comptes séparés et barrières avant visibilité restent la baseline 2026. Les Mac hébergés ne remplacent pas les manifestes mais réduisent les collisions humain/automation.

Links

xattr APFS

files-from