Ho una risposta, e risponde anche all'enigma di User-12140973118483743392.
Pensa di non averne bisogno, ma quindi fallisce in certi casi limite.
Windows opera su un modello "chiedi perdono".
Così, per mostrare le opzioni disponibili, Mac OS X chiede il permesso, su ciò che gli è permesso di fare ad un oggetto. Poi mostra solo le opzioni disponibili. Questo è il motivo per cui, in un programma Mac OS X scritto correttamente, qualcosa non verrà mostrato come una zona di rilascio valida, se state, per esempio, trascinando un tipo di documento che non capisce sopra la sua icona.
Windows, d'altra parte, vi mostrerà tutte le opzioni disponibili, e poi potrete provarle, e avrete un errore se non funziona (generalmente un bong; a volte più esteso).
La premessa di base di Apple qui - che non è corretta per i moderni sistemi informatici - è che è possibile prefissare l'operazione prima di tentare l'operazione, e poi si possono mostrare le opzioni, e poi fare l'operazione.
La ragione per cui questo non è corretto per i moderni sistemi informatici è che essi possono essere multiutente - anche se gli utenti non sono sullo stesso computer.
Così se si prende, per esempio, un file server che è condiviso in comune con un certo numero di macchine, è possibile prefigurare un'operazione, come "trascinare un documento dalla cartella A alla cartella B", e ottenere la risposta "sì, questo è permesso". Ma tra il momento in cui chiedete se è permesso, e poi eseguite l'azione sulla base della vostra comprensione che è un'operazione consentita - è possibile che un altro utente entri e cambi i permessi sull'oggetto che state trascinando, la cartella di origine, o la cartella di destinazione, in modo tale che l'operazione non sia più consentita.
Mac OS X tende a gestire male tali errori.
Al contrario, Windows gestisce queste operazioni allo stesso modo: permettendo che l'operazione sia tentata - anche se è insensata nel momento in cui il tentativo viene avviato. O funziona, o lancia un errore.
Perché questo è un risultato atteso - mancando una capacità di preflight per qualcosa come isValidDropTarget(fileType) - Windows si aspetta la possibilità di un errore, e lo gestisce correttamente. Il rovescio della medaglia è che presenta opzioni senza senso, ma il lato positivo è che il software avrà percorsi di errore ben definiti.
Quindi il risultato è che il sistema Mac OS X può - e lo fa - aspettarsi notifiche di cambiamento del filesystem per tutte le cartelle aperte - anche se sono su un server remoto, che può essere collegato usando un protocollo di file system remoto (ad esempio WebDAV, NFS, ecc.), che non può assolutamente fornire tali notifiche.
Così per i file locali - e per i filesystem remoti AppleTalk, per i quali esegue il polling del tempo di accesso alla cartella ogni 11 secondi - Mac OS X può aggiornare automaticamente il contenuto delle cartelle.
Ma è imperfetto, e non funziona per alcuni filesystem remoti, network attached storage, o potenzialmente anche in altri casi.
Sembra funzionare solo per te, perché sei un singolo utente, e lo storage è (effettivamente) locale.