Change events only fire once

[hbmartin]

I'm having a problem change events are only fired once for a given file. I'm running node v0.8.9 on Mac OS X 10.8 Mountain Lion.
Here's sample output from the included example script:
watching everything completed
a log message occured: { '0': 'debug',
'1': 'watch event triggered on ui-resizable.css:',
'2': [ 'change', null ] }
a log message occured: { '0': 'debug',
'1': 'determined update:',
'2': 'ui-resizable.css' }
a change event occured: ui-resizable.css

Subsequent updates to the css file display none of these message.
What am I doing wrong?

[balupton]

By default the same change is not fired if it happens within 1 second of the previous one. But sounds like for you it is indefinite, rather than one second. So could be a bug in https://github.com/bevry/watchr/blob/master/src/lib/watchr.coffee#L250-L284 however I am not affected by it.

Will look into this, if you can look into it too that'll be appreciated. Thanks!

[dweldon]

I'm having the same issue in my Cakefile. Everything was working fine for me with node 0.8.18, but broke around the time I transitioned to 0.8.19. I'm uncertain if it's related however. The node change log doesn't indicate any changes to fs.

[dweldon]

Looks like this doesn't have anything to do with the node version - that was coincidental. I experimented with different versions of watchr and found that 2.3.3 works great, but versions >= 2.3.4 have this problem. Could this be related to the switch to fs.watch? I'm running Ubuntu 12.10 if that helps.

[oscar-broman]

Same problem here. 2.3.3 behaves as it should. I'm on OS X 10.8.2 with Node v0.8.19.

It seems to work just fine when duplicateDelay is 0, however.

[dweldon]

I tried setting duplicateDelay to 0, but that did not fix it for me. Bummer.

[tapio]

I'm too affected by this. My work-around is to change the method back to preferring watchFile over watch with this parameter: preferredMethods: [ 'watchFile', 'watch' ]. I also needed to lower the interval parameter as nowadays its default is 5007 milliseconds, which is too long for my purposes.

[hermiteu]

Same problem using node v0.10.0, DocPad v6.26.0, Watch 2.3.7, latest OS X Mountain Lion. I can change every file once, so one change to index.html.md, 1 change to scripts.js, etc. After that no detection of changes, no matter how big the change is. I'm new to node and docpad, I'm not sure how to check if watchr 2.3.3 works.

[tapio]

@hermiteu: If you have a package.json in your project, specify "watchr": "2.3.3" in the dependencies section and do npm install. If, on the other hand, you manage dependencies manually, you can command this: npm install watchr@2.3.3

[hermiteu]

Thanks tapio! Using Watchr 2.3.3 everything works fine.

[caseywebdev]

Running into this also. The culprit is in 770cd65 somewhere but @balupton would know best where exactly it is.

[balupton]

Thanks for all the feedback everyone.

While we could set the default preferredMethods back to ['watchFile','watch'] it would introduce the same problems we had before; large memory loads, large CPU load, longer detection delays, under certain circumstances.

Ideally, it would be great if we could use the watch method for environments that support it, and watchFile for environments that don't, and detect this automatically. Unfortunately, I'm not yet able to reproduce this issue, even on shared drives. I'm on OSX Mountain Lion and tried with Node 0.8 and Node 0.10.

For those of you who are able, and want to help out with the fix, I'll need the following from you, it'll be a great help:

1. The operating system you are on
2. The node version you are using
3. The watchr version you are using

Next, we need to do some debugging, I need the result of the following command:

node -e "require('fs').lstat(process.cwd()+'/THEFILENAME',console.log.bind(console))"

Please run this twice and provide the result for both. Once on a file that watchr works fine on. Again on a file that watchr doesn't work fine on. Make sure you are using the latest version of watchr with the default configuration. Change the THEFILENAME portion with the name of the file.

Hopefully that will provide us with some indication of what the difference is between working and non working files. Thanks.

[balupton]

For a little background of this issue, it seems to be a combination of duplicateDelay and preferredMethods.

preferredMethods

The watch method (which is now the preferred method) uses the operating system's watching abilities, whereas the watchFile method used node.js polling, which is the reason why watchFile worked.

The issues with watchFile is that it has increased CPU and memory load as we have to do the polling for every file ourselves, and when the interval option is lower, this can cause severe problems as all our app is doing is polling files!

The issues with watch if that sometimes the operating system's watching abilities aren't that good, however it solves the issues of watchFile when it actually works.

duplicateDelay

The duplicateDelay is that sometimes watching just fires duplicate events for whatever reason, so we do some detection to see if the event is the same as one within the duplicateDelay and if it is, then don't worry. This also takes the size of the file into consideration and the modification date so it should be quite intelligent, but perhaps not. In v2.3.9 I've made it so if duplicateDelay is falsey we don't do any duplicate detection.

conclusion

So it is a rock in a hard place scenario. Hopefully with the feedback from the steps in my previous comment we'll be able to figure out the differences between the situations where watchFile or watch is preferred, and selection the correct one intelligently and automatically. Be it even if we even have to fallback to a whitelist/blacklist of the operating systems.

For now, the best I can recommend is adjusting those two settings for yourself. While I could revert back to v2.3.3 way of doing things, then we'll have a different set of people complaining of issues instead - so that's not an option.

Hope that adds some understanding to the complexity of the situation. Cheers.

[caseywebdev]

With OS X 10.8.2, Node.js 0.10.0, and watchr 2.3.9, the first change per file will always trigger, but subsequent changes on the same file will never trigger. This is true for every of the 4 possible preferredMethod/duplicateDelay combinations as well. Here's a stat on one of files

{ dev: 16777218,
  mode: 33188,
  nlink: 1,
  uid: 501,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 18100802,
  size: 1102,
  blocks: 8,
  atime: Sun Mar 17 2013 12:33:54 GMT-0500 (CDT),
  mtime: Sun Mar 17 2013 12:33:52 GMT-0500 (CDT),
  ctime: Sun Mar 17 2013 12:33:52 GMT-0500 (CDT) }

[dweldon]

It may be worth having a look at how fs-watch-tree is implemented. For me, it doesn't suffer from the same issue, but seems to use fs.watch.

[balupton]

Which editor and editor version is everyone using?