J'ai une réponse, et elle répond également à l'énigme de User-12140973118483743392.
Il pense qu'il n'en a pas besoin, mais échoue donc dans certains cas de coin.
Mac OS X fonctionne sur un modèle de "demande de permission".
Windows fonctionne sur un modèle de "demander pardon".
Donc, pour afficher les options disponibles, Mac OS X demande la permission, quant à ce qu'il est autorisé à faire à un objet. Ensuite, il ne montre que les options disponibles. C'est pourquoi, dans un programme Mac OS X correctement écrit, quelque chose n'apparaîtra pas comme étant une zone de dépôt valide, si vous faites, par exemple, glisser un type de document qu'il ne comprend pas sur son icône.
Windows, en revanche, vous affichera toutes les options disponibles, et vous pourrez alors les essayer, et vous obtiendrez une erreur si cela ne fonctionne pas (généralement un bang ; parfois plus étendu).
La prémisse de base d'Apple ici - qui est incorrecte pour les systèmes informatiques modernes - est qu'il est possible de prévisualiser l'opération avant de la tenter, et ensuite vous pouvez afficher les options, puis faire l'opération.
La raison pour laquelle cela est incorrect pour les systèmes informatiques modernes est qu'ils peuvent être multi-utilisateurs - même si les utilisateurs ne sont pas sur le même ordinateur.
Si vous prenez, par exemple, un serveur de fichiers qui est partagé en commun avec un certain nombre de machines, il est possible de prévisualiser une opération, comme "glisser le document du dossier A au dossier B", et d'obtenir la réponse "oui, c'est autorisé". Mais entre le moment où vous demandez si c'est autorisé, puis où vous effectuez l'action en vous basant sur votre compréhension du fait que c'est une opération autorisée - il est possible qu'un autre utilisateur arrive et modifie les autorisations sur l'objet que vous faites glisser, le dossier source ou le dossier de destination, de telle sorte que l'opération n'est plus autorisée.
Mac OS X a tendance à mal gérer de telles erreurs.
En revanche, Windows gère ces opérations de la même manière : en autorisant la tentative d'opération - même si elle est insensée au moment où la tentative est lancée. Soit elle fonctionne, soit elle jette une erreur.
Parce que c'est un résultat attendu - l'absence d'une capacité de contrôle en amont pour quelque chose comme isValidDropTarget(fileType) - Windows s'attend à la possibilité d'une erreur, et la gère correctement. Avec l'inconvénient que cela présente des options absurdes, mais l'avantage étant que le logiciel aura des chemins d'erreur entièrement étoffés.
Donc, le résultat est que le système Mac OS X peut - et attend - des notifications de changement de système de fichiers pour tous les dossiers ouverts - même s'ils sont sur un serveur distant, qui peut être attaché en utilisant un protocole de système de fichiers distant (par exemple WebDAV, NFS, etc.), qui ne peut éventuellement pas fournir de telles notifications.
Donc, pour les fichiers locaux - et pour les systèmes de fichiers distants AppleTalk, dont il interroge le temps d'accès au dossier toutes les 11 secondes - Mac OS X peut rafraîchir automatiquement le contenu des dossiers.
Mais c'est imparfait, et cela ne fonctionne pas pour certains systèmes de fichiers distants, pour le stockage attaché au réseau, ou potentiellement dans d'autres cas aussi.
Il ne semble fonctionner pour vous que parce que vous êtes un utilisateur unique, et que le stockage est (effectivement) local.