Lorsque le code ci-dessous est couru, la montre est déclenchée uniquement si je modifierais et sauvegardez manuellement le tmp.txt, en utilisant mon IDE, TextEditor.app ou Vim.
Il ne fonctionne pas par la méthode du flux d'écriture ou Redirection de sortie de shell manuelle (Typing Echo "Test"> /path/to/tmp.txt").
Bien que si je regarde le fichier lui-même, et non son dirname, alors ça marche. P >
var fs, Path, file, watchPath, w;
fs = require('fs' );
Path = require('path');
file = __dirname + '/tmp.txt';
watchPath = Path.dirname(file); // changing this to just file makes it trigger
w = fs.watch ( watchPath, function (e,f) {
console.log("will not get here by itself");
w.close();
});
fs.writeFileSync(file,"test","utf-8");
fs.createWriteStream(file, {
flags:'w',
mode: 0777
} )
.end('the_date="'+new Date+'";' ); // another method fails as well
setTimeout (function () {
fs.writeFileSync(file,"test","utf-8");
},500); // as does this one
// child_process exec and spawn fail the same way with or without timeout
3 Réponses :
Le truc est, vous avez demandé à regarder le répertoire et non le fichier . Le répertoire n'est pas mis à jour lorsque le fichier est modifié , telle que la redirection de la coque; Dans ce cas, le fichier est ouvert, modifié et fermé. Le répertoire n'est pas modifié - seul le fichier est. Lorsque vous utilisez un éditeur de texte pour modifier un fichier, l'ensemble habituel des appels système dans les coulisses ressemble à ceci: < pré> xxx de cette façon, le fichier foo est entièrement l'ancien fichier ou entièrement du nouveau fichier, et il n'y a aucun moyen pour y avoir un "fichier partiel" avec le Nouveau contenu. Les opérations de renommage font modifient le répertoire, déclenchant ainsi la montre de répertoire.
Fondamentalement, les mêmes informations que dans ma réponse simultanée, mais je pense que c'est plus lisible que le mien, alors je lavie.
@Abarnert: Mais le ping était une bonne idée, votre réponse vaut vraiment la peine de +1. :)
Il ne déclenche pas car une modification du contenu d'un fichier n'est pas une modification du répertoire.
Sous les couvercles, au moins à partir de 0,6, Fs.Watch sur Mac utilise KQueue, et c'est un wrapper assez mince autour des notifications du système de fichiers KQueu. Donc, si vous voulez vraiment comprendre les détails, vous devez comprendre KQueu, et des inodes et des choses comme ça.
Mais si vous voulez une courte explication "mensonge à enfants": ce qu'un utilisateur pense en tant que "fichier" est vraiment deux choses distinctes - le fichier réel et la saisie de répertoire qui pointe vers le fichier réel. C'est ce qui vous permet d'avoir des choses comme des liens difficiles et des fichiers qui peuvent toujours être lus et écrits même après leur avoir supprimé, etc.
En général, lorsque vous écrivez dans un fichier existant, cela ne modifie pas la saisie de répertoire, alors tout le monde qui regardait le répertoire ne verra aucun changement. C'est pourquoi echo> tmp.txt ne vous déclenche pas.
Cependant, si vous, par exemple, écrivez un nouveau fichier temporaire, puis déplacez-le sur l'ancien fichier, qui modifie l'entrée de répertoire (ce qui en fait un pointeur sur le nouveau fichier au lieu de l'ancien), de sorte que vous serez donc notifié. C'est pourquoi TextEditor.app vous déclenche.
Bien que les réponses ci-dessus semblent raisonnables, elles ne sont pas complètement précises. Il s'agit en fait d'une fonctionnalité très utile pour pouvoir écouter un répertoire pour les modifications de fichier, pas seulement "renommé". Je pense que cette fonctionnalité fonctionne comme prévu sous Windows au moins, et dans le nœud 0.9.2 fonctionne également pour Mac, car ils ont changé vers l'API des Fsevents prenant en charge la fonctionnalité:
Il suffit de changer Fs.watch -> fs.watchfile et c'est fait. Réf: git-link