Changes to the same file are not detected

[tnguyen14]

I'm having an issue where the watcher can detect changes in a file for the first time, but after that subsequent changes are not detected, no matter how long the interval is.

I am running Yosemite beta on my Macbook, I'm not sure if that has anything to do with it.

Is anyone facing the same issue?

[paulmillr]

chokidar version?

[paulmillr]

node version?

[tnguyen14]

chokidar version 0.8.2, node version 0.10.28

[amillward]

I have this problem too. Node v0.10.30, chokidar v0.8.2. http://stackoverflow.com/questions/25081880/brunch-watch-isnt-compiling-changed-files

[tnguyen14]

I just update watchify to use 0.8.4 and am still experiencing the same issue. First file change is detected, subsequent changes are not. Please reopen the issue.

[paulmillr]

Are u running with usepolling or w/o? Try diff option

[jacobsvante]

Maybe they've made some changes to the FSEvents API? Anyone else experiencing this on Yosemite?

[paulmillr]

so?

Are u running with usepolling or w/o? Try diff option

[tnguyen14]

That's really weird that you're not seeing the same issue. Watchify by default don't set usePolling, which I assume is set to true. I tried setting it to false but that doesn't seem to make a difference.

[amillward]

I'm also still having this problem. I must set usePolling = true to get file changes.

[paulmillr]

@amillward are you on OS X?

usePolling = true on OS X and Linux by default.

[amillward]

I'm on Ubuntu 14.04 and not using the default. Always specifying either true or false.

On 26 August 2014 12:43, Paul Miller notifications@github.com wrote:

@amillward https://github.com/amillward are you on OS X?

usePolling = true on OS X and Linux by default.

— Reply to this email directly or view it on GitHub https://github.com/paulmillr/chokidar/issues/138#issuecomment-53407750.

[reintroducing]

Just wanted to check in and see if there was any headway made on this? Thanks for your hard work.

[nopnop]

@tnguyen14 : Maybe this PR #150 could be related to this issue. I had the same issue (side effect) with watchify (I need to watch the same files with another chokidar instance): And watchify close watchers on each change.

[reintroducing]

Hey Paul, Apologies for the delay but I finally got around to creating a repo that demonstrates this issue. You can grab the code here: https://github.com/reintroducing/threshold-gulpify-bb (either clone the repo and run it using grunt-init or just grab the contents of the root folder to get started immediately). Here are the steps to reproduce:

1) npm install 2) gulp 3) Open js/app.js and make any changes in it (just a log or whatnot). 4) Observe terminal, the change is recorded and the appropriate tasks are run (in this case lint and browserify). 5) Make another change in the same file and observe terminal again. Tasks run as expected. 6) ctrl+c in terminal to kill the watch and open up gulp/tasks/browserify.js. 7) Uncomment line 30-33 to add watchify to the task and run gulp again. 8) Repeat steps 3-5. You will observe that the first few times the lint and browserify tasks run. Sometimes once, sometimes twice (meaning after a second edit/save), and then they stop and all you see reporting in terminal is [BS] 1 file changed (main.js) for subsequent edits but the tasks don't run anymore.

I'm on OSX 10.9.5, node v0.10.31, npm 2.0.0-beta.0, chokidar 0.8.4

Let me know if you have any questions and hopefully this helps you track down the issue.

[paulmillr]

I will check this but i'm currently slow :( since this issue happens to some people not to all of them

Anyone willing to help? I'm seeking for a new chokidar maintainer BTW. @es128 maybe?

[es128]

Sure I can try to take a more active role here

@shama @amasad Would either of you have any interest in pitching in?

[es128]

@reintroducing I just tried your test case, and was able to reproduce as you described. However, I'm not sure I understand your project structure. It seems like you have 3 watchers running at once - gulp-watch, browsersync, and watchify?

What does the watchify part of your browserify task accomplish beyond what was happening when it was commented out?

Any way to reduce this test case to remove all the noise?

[es128]

Furthermore, I was able to confirm that chokidar does continue to emit events (albeit, possibly duplicates of the events), even when the task doesn't end up getting run. In fact, I can trace this back all the way to the point of your bundle function being run. Add a breakpoint or console.log at https://github.com/reintroducing/threshold-gulpify-bb/blob/master/root/gulp/tasks/browserify.js#L20 to see what I mean. That's what seems to trigger then [BS] 1 file changed (main.js) message you mentioned.

So the problem seems to be somewhere downstream from there, but not because chokidar stops detecting changes.

[shama]

@es128 FWIW, I've been working on a platform layer for watch libs: https://github.com/shama/navelgazer It is still in progress though and I'm not sure if the goals there align with chokidar or not (for instance I'm using kqueue for OSX instead of fsevents atm).

My plan is to test a bit more in my own workflow, then start implementing into the higher level watch libraries I currently maintain. I wouldn't mind attempting to implement into to chokidar as well if there is interest.

[es128]

@shama Looks very cool, and I'd certainly be interested in learning more as the project matures.

The advantage of fsevents in chokidar is that it reduces CPU load to nearly 0, even when watching very large projects. Does kqueue do the same?

[shama]

Yes, kqueue also doesn't use much CPU while watching a large amount of files. The main downside of kqueue is you need to open a file descriptor for each file, thus hitting EMFILE a lot sooner. But since kqueue operates on individual files, I've found it to respond quicker and more reliably (especially when trying to be consistent on Windows and Linux).

I would like to experiment with fsevents more though, at the very least as an alternative fallback for when a user hits EMFILE instead of stat polling.

[es128]

@reintroducing @tnguyen14 @amillward

Can anyone demonstrate the problem in latest chokidar? The use case provided so far appears to be an implementation problem, chokidar is still emitting change events as expected.

The thread has meandered, so I'm tempted to close it and ask that a new one be opened if the problem can be described/demonstrated adequately enough to be debugged.

[reintroducing]

@es128 You are right, it seems that it is an implementation problem on my end. The gulp-starter repo that I originally based my repo on works correctly so I think I just need to re-evaluate how I'm using it and implement in the same way he does there. Thank you for clearing this up for me.

[es128]

As mentioned above, closing. Anyone who is still experiencing this type of problem, please open a new issue and provide a reproducible test case.

[kirillrdy]

I hope this saves someone some time. I've had same issue as @tnguyen14 changes to file were only detected once, and never for subsequent changes. Turned out it was because of vim. It would create a different file. chokidar would catch unlink event and remove file from watch list. :cry:

[jugheadjones10]

@kirillrdy
Your comment saved my life…I’ve been trying to figure this out for like one week. This has the solution that worked for me.