Lorsqu'un observateur de fichiers Mac manque des modifications, déterminez d'abord si le changement atteint le dossier surveillé, si l'application voit les événements du système de fichiers, et si elle filtre ou ne parvient pas à les traiter. Reproduisez une modification manquée dans un petit fichier connu, puis comparez ce résultat avec un fichier du grand projet. Cette séquence permet de distinguer la configuration du projet de la transmission des événements et du traitement par l'application.

1. Confirmer le chemin exact et la modification

Dans l'application concernée, vérifiez quel dossier est ouvert en tant qu'espace de travail et confirmez que le fichier modifié se trouve bien à l'intérieur de ce dossier. Un fichier peut apparaître dans un éditeur tout en se trouvant en dehors de la racine surveillée ; les liens symboliques peuvent également se comporter différemment des dossiers imbriqués ordinaires. Par exemple, VS Code documente que son observateur macOS utilise FSEvents, que les liens symboliques ne sont pas suivis automatiquement, et que son paramètre d'exclusion de l'observateur peut omettre des chemins. Ces détails s'appliquent à VS Code, et non à toutes les applications Mac ; vérifiez donc les paramètres d'espace de travail et d'exclusion équivalents dans votre propre outil. VS Code: File Watcher Issues

Enregistrez une modification simple dans un fichier situé directement à l'intérieur du projet, puis vérifiez si l'application réagit. Si seul un chemin généré, ignoré, lié ou profondément imbriqué échoue, examinez l'inclusion de ce chemin et sa relation avec la racine de l'espace de travail avant de considérer qu'il s'agit d'un problème général à l'échelle de macOS. Si le projet se trouve sur un lecteur réseau mappé ou utilise un système de fichiers tiers, testez une copie sur le disque local du Mac. VS Code avertit que ces systèmes de fichiers ne garantissent pas la génération d'événements ; c'est une raison pour comparer les environnements, et non la preuve que chaque volume de ce type échoue.

2. Vérifier si l'application a reçu des événements

Les notifications du système de fichiers ne constituent pas la promesse d'un rappel précis pour chaque modification individuelle. La documentation FSEvents d'Apple indique que les événements peuvent être regroupés ; lorsque le drapeau MustScanSubDirs est défini, un client doit réanalyser de manière récursive le répertoire indiqué. Les drapeaux d'événements abandonnés (dropped events) signalent des problèmes de mise en mémoire tampon et nécessitent une analyse complète des répertoires surveillés. Cela signifie qu'un observateur bien conçu doit concilier le contenu actuel du répertoire, plutôt que de se fier uniquement à une séquence parfaite de notifications. Apple: Using the File System Events API, Apple: FSEventStreamEventFlags

Recherchez des journaux ou des diagnostics de l'observateur dans l'application qui manque la modification. Pour VS Code, sa documentation décrit l'activation de la journalisation détaillée de l'observateur de fichiers et l'inspection de la sortie de journal correspondante. D'autres applications peuvent exposer des diagnostics différents, voire aucun. Si le journal signale des événements abandonnés, des exclusions, une racine obsolète ou une erreur de l'observateur, conservez ce message et suivez les étapes de récupération propres à l'application ; redémarrer l'observateur ou l'application peut constituer une comparaison contrôlée utile, mais n'identifie pas la cause sous-jacente en soi.

3. Utiliser fs_usage pour inspecter l'activité du système de fichiers

macOS inclut fs_usage, qui affiche l'activité continue des appels système liés au système de fichiers. Cet outil peut aider à déterminer si l'application concernée accède à des fichiers lors d'une reproduction, mais ce n'est pas un visualiseur d'événements FSEvents et il ne peut pas prouver que l'observateur a reçu ou traité une notification. Apple précise que des contrôles d'accès s'appliquent et qu'un accès root peut être requis. Apple: Examining File-System Usage

Dans Terminal, reproduisez le problème tout en observant l'application désignée. Remplacez YourApp par le nom réel de son processus (par exemple, le nom de processus d'une application peut différer de son nom d'affichage) :

sudo fs_usage -w YourApp

Arrêtez l'affichage en direct avec Contrôle-C après la brève reproduction. La sortie pouvant être très dense, concentrez-vous sur l'heure de la modification et sur les chemins pertinents. Si le nom du processus est incertain, consultez la documentation de l'application ou le Moniteur d'activité ; ne partez pas du principe que le filtrage par un nom deviné affichera le bon processus. fs_usage est une aide au diagnostic pour l'activité des fichiers, et non une commande permettant de réinitialiser ou de réparer un observateur.

4. Comparer l'échelle et les conditions d'accès

Répétez la même modification dans un petit dossier de test local que l'application peut surveiller. Si cela fonctionne alors que le grand projet échoue, comparez les exclusions spécifiques au projet, les liens symboliques, les répertoires générés et tous les chemins distants ou gérés par un fournisseur. Les arborescences volumineuses génèrent plus de travail tant pour la gestion des événements que pour la réanalyse ; les directives d'Apple indiquent clairement que les notifications peuvent nécessiter des analyses récursives, tandis que l'application décide de la manière de gérer ce travail. La corrélation avec la taille ne suffit pas à elle seule pour établir une limite de file d'attente d'événements du système d'exploitation.

Vérifiez si l'application concernée peut accéder à l'emplacement du projet. Les contrôles de confidentialité de macOS et les règles d'App Sandbox peuvent restreindre l'accès aux dossiers, et Apple documente que l'accès aux emplacements protégés peut nécessiter une autorisation de l'utilisateur dans les Réglages Système. Vérifiez l'état des autorisations de l'application sous Réglages Système > Confidentialité et sécurité, et accordez uniquement l'accès nécessaire pour la tâche. Un problème d'autorisation peut empêcher un accès utile aux fichiers même lorsque le chemin apparaît dans l'application. Apple: Accessing Files from the macOS App Sandbox

5. Choisir l'étape suivante à partir des éléments constatés

Si le petit dossier local fonctionne, envoyez au développeur de l'application une reproduction minimale indiquant le type d'emplacement du projet, le modèle de chemin concerné, le journal pertinent de l'observateur et si un lien symbolique ou une exclusion est en jeu. Si les dossiers locaux, petits comme grands, échouent, mettez à jour l'application et consultez son outil de suivi des problèmes spécifique à la version de macOS ou ses conseils d'assistance ; indiquez la version de macOS et celle de l'application. Évitez de supprimer des données du projet ou de modifier les paramètres de sécurité du système en guise de correctif spéculatif. Le diagnostic utile correspond à la condition reproductible la plus étroite : une application, un chemin, une modification et un échec observable.

Sources