Also, doing a 'mv test.txt other.txt' seems to go completely unnoticed by fs.watch. I expected a 'renamed' event while inotify tracked the actual filesystem object (not the name which is used only initially to pick the file).
I must be braindead. I knew switching to decaff this month was a bad idea... On Fri, Mar 16, 2012 at 8:44 AM, 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
