Our PR landed in 4.1.0, so we no longer need a fork.
Hopefully, the runas-related bug which causes dev bundle builds to
sometimes fail (which is why we moved the install to its own step) is
fixed with the newer version of runas used by pathwatcher now.
Note that we were previous using a fork with an early version of our PR,
which put the numeric errno on 'code'. The accepted version of the PR
puts the numeric errno on 'errno' (and in Node 0.12, puts a string on
'code').
Instead, increase polling interval for that file/dir to 500ms from 5s.
Fixes#3336.
The most common case where this was occuring is when you're on Linux and
your inotify max_user_watches is too low. A wiki page will explain how
to increase this. In debug mode, a message will tell you to go to the
wiki page if you hit the limit (we may later expose this message by
default, but it is part of the new user experience).
Conflicts:
meteor
tools/safe-pathwatcher.js
Instead, increase polling interval for that file/dir to 500ms from 5s.
Fixes#3336.
The most common case where this was occuring is when you're on Linux and
your inotify max_user_watches is too low. A wiki page will explain how
to increase this. In debug mode, a message will tell you to go to the
wiki page if you hit the limit (we may later expose this message by
default, but it is part of the new user experience).
This strategy was suggested by @glasser after we realized just how
hopeless it is to probe the file system to test pathwatcher:
https://github.com/meteor/meteor/issues/3285#issuecomment-67296961
I've made some attempt to de-duplicate these events (since we're
effectively watching twice now), but we have other mechanisms for dealing
with bursty file change events, so these measures do not need to be
completely bulletproof.
Fixes#3284 (again).
This strategy was suggested by @glasser after we realized just how
hopeless it is to probe the file system to test pathwatcher:
https://github.com/meteor/meteor/issues/3285#issuecomment-67296961
I've made some attempt to de-duplicate these events (since we're
effectively watching twice now), but we have other mechanisms for dealing
with bursty file change events, so these measures do not need to be
completely bulletproof.
Fixes#3284 (again).
Previously we were testing pathwatcher.watch by creating a file in
.meteor/local, but developers using Vagrant VMs often mount .meteor on a
different (non-network) file system, for Mongo's sake.
Writing the file directly in the app directory increases the likelihood
that it will interact with pathwatcher in the same way as other source
files the developer will be editing.
Conflicts from devel:
tools/safe-pathwatcher.js
Previously we were testing pathwatcher.watch by creating a file in
.meteor/local, but developers using Vagrant VMs often mount .meteor on a
different (non-network) file system, for Mongo's sake.
Writing the file directly in the app directory increases the likelihood
that it will interact with pathwatcher in the same way as other source
files the developer will be editing.
