When you watch a file you're actually watching an inode (a magic number that represents the file). If that file gets deleted and another one with the same name gets created, it's not the same file (it will have a different inode). Likewise if you replace a file with mv(1).
This is the difference between tail -f and tail -F for example: the latter watches to see if the file is replaced by another. If gedit is saving the current buffer into a temporary file then moving it over the new one (a common approach because moving a file is atomic) you will no longer see watch events on the new file. You can add another watch to the directory containing the file, then you'll see the create, remove, rename, etc. events in that and you should be able to spot what's going on and create a new watch for the new file (and close the old one of course). On 16 March 2012 15:44, C. Mundi <[email protected]> wrote: > > > On Fri, Mar 16, 2012 at 7:33 AM, Ben Noordhuis <[email protected]> wrote: > >> On Fri, Mar 16, 2012 at 06:34, C. Mundi <[email protected]> wrote: >> > I am aware that there are platform-specific issues with watching >> files. But >> > I am getting strange-bad results just on Linux. Please tell me I am >> doing >> > something silly below. >> > >> > var fs = require('fs'); >> > >> > function act(curr, prev) { >> > console.log('the current mtime is: ' + curr.mtime); >> > console.log('the previous mtime was: ' + prev.mtime); >> > }; >> > >> > function act2(event,file) { >> > console.log('event is: ' + event); >> > if (file) { >> > console.log('filename provided: ' + file); >> > } else { >> > console.log('filename not provided'); >> > } >> > }; >> > >> > // ucomment one or the other (but not both!) of the following lines: >> > // fs.watchFile('test.txt', act); >> > // fs.watch('test.txt', act2); >> > >> > When I use fs.watch + act2, and simply repeatedly 'touch' the file >> (about >> > once per second) the first two events are 'change' and the next three >> are >> > 'rename' (!) and then program just stops producing output. It's as if >> the >> > events are eitehr never fired or never handled. I understand that this >> is >> > based (on Linux) on inotify? >> > >> > So I switch to fs.watchFile + act. Again, I 'touch' the test file about >> > once per second. This always produces an event. The problem is, about >> 30% >> > of the time one touch produces two events! And about 5% of the time, >> one >> > touch produces three events! I understand that this is actually a >> polling >> > solution, and... >> > >> > My own naive polling code does not have these problems. At least it >> does >> > not seem to. >> > >> > I need the action to run reliably (which seems to eliminate fs.watch) >> and >> > exactly once (which seems to eliminate fs.watchFile) so it seems I am >> stuck >> > with my own clunky polling solution. Again: Am I doing something silly? >> > >> > Thanks! >> >> With what version of Node and what kernel are you seeing this? >> fs.watch() should be the more reliable option provided you don't flood >> it with events. >> >> `uname -a` will tell you your kernel version, `sysctl >> fs.inotify.max_queued_events` shows the size of the event backlog >> (16384 on most systems). >> >> - > > > Hi Ben. Thank for your reply. I should have included this of course: My > kernel is updated to > > $ uname -a > Linux zaphod 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012 > x86_64 x86_64 x86_64 GNU/Linux > > and > > $ sysctl fs.inotify.max_queued_events > fs.inotify.max_queued_events = 16384 > > as expected. > > Ok, I think I found the problem, but I do not understand. > > When I literally use "touch" to touch test.txt, both fs.watch and > fs.watchFile work as advertised. But if I open test.txt with an editor > (gedit for example) and Save it from there, that's when the problems > happen. I guess I'm not too surprised at the multiple events (the editor > might do that) but the spurious renames are interesting (maybe caching a > copy and then replacing the origianal?) and what I absolutely do no > understand is why the fs.watch solution actually jams. For example: > > start my script > literally 'touch test.txt' a few times -- ok > now "Open" test.txt in gedit and "Save" twice -- get a combination of > changed and renamed events > At this point, the script is no longer getting and/or responding to events. > 'touch test.txt' --> script does nothing > close gedit > 'touch test.txt' --> script does nothing > > So it appears that gedit has somehow hijacked or suppressed future events. > > If I start up a second instance of node (leaving the first one running) > then the second instance does receive and respond to events triggered by > 'touch test.txt' while the first instance remains stuck. > > Ok, this is probably not about node. But people using node might want to > know about this behavior. I certainly did not expect a userspace app like > gedit to affect whether inotify events get to node. > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
