Skip to content

Loading…

Error "watch ENOSYS" when using watch-switch #2113

Closed
sattes-faction opened this Issue · 13 comments

9 participants

@sattes-faction

Whenever I try to run the following, it fails:

someuser@localhost:~/work/project$ coffee -o web/javascripts/ -wc coffeescripts/

/usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:287
  if (e.code !== 'ENOENT') throw e;
                             ^
Error: watch ENOSYS
at errnoException (fs.js:636:11)
at FSWatcher.start (fs.js:663:11)
at Object.watch (fs.js:691:11)
at /usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:256:27
at Object.oncomplete (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:85:25)

I'm using CoffeeScript 1.2.0, nodejs 0.6.10 (at least that's what node -v tells) on Debian squeeze.

@csubagio

I updated to 1.2.0 on OSX 10.7.2, and I'm seeing this too now.

Also seeing the same if I try to use fs.watch in node rather than fs.watchFile.

@TrevorBurnham
Collaborator

Odd. ENOSYS means the OS is saying "Sorry Node, you can't watch that file." I've never experienced this. Is there something special about the coffeescripts directory? Could it be a permissions problem?

@csubagio

I think think this was happening because I had a volatile version of node on this machine. I upgraded to v0.7.4, and the problem has abated.

I am getting a warning now though: path.exists is deprecated. It is now called 'fs.exists'. Looks like something is about to get yanked out from under coffee's feet.

@danielberndt

Same here on Mac OS X 10.5.8 with:

node v0.6.11
CoffeeScript version 1.2.0

$ sudo coffee -o public/javascripts -wc client_src/coffee/*.coffee

/usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:227
      if (e.code !== 'ENOENT') throw e;
                                     ^
Error: watch ENOSYS
    at errnoException (fs.js:636:11)
    at FSWatcher.start (fs.js:663:11)
    at Object.watch (fs.js:691:11)
    at /usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:232:27
    at Object.oncomplete (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:106:25)
@jashkenas
Owner

Not seeing the deprecation yet on the stable 0.6 series -- where:

> require('fs').exists
undefined

... so not going to change it yet either.

@jashkenas jashkenas closed this
@danielberndt

just upgraded my system to Mac OS X 10.7.3 and got a fresh install from nodejs and coffe-script (the stable stuff) and the issue is still there:
~ % coffee -w .

/usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:287
      if (e.code !== 'ENOENT') throw e;
                                     ^
Error: watch EMFILE
    at errnoException (fs.js:636:11)
    at FSWatcher.start (fs.js:663:11)
    at Object.watch (fs.js:691:11)
    at /usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:256:27
    at Object.oncomplete (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/command.js:85:25)
@jashkenas jashkenas reopened this
@kitcambridge

ENOSYS usually means that an environment doesn't support a particular function...I've found that it occurs on OS X if you use the osx-gcc-installer instead of the Xcode Command Line Tools or full Xcode suite (both ship with several proprietary headers that Node requires, but that aren't bundled with osx-gcc).

Not sure of what to make of EMFILE, though...this page wasn't very helpful. Perhaps your working directory contains too many files?

@danielberndt

the new stable of node (Version 0.6.12) fixes this bug (see also http://blog.nodejs.org/2012/03/02/version-0-6-12-stable/ )

@jashkenas jashkenas closed this
@jkenneydaniel

I have Nodev0.6.13 and CoffeeScript 1.2.0 and this is still happening. Per danielberndt this was fixed in 0.6.12, so apparently creeped back in v0.6.13.....

@shahkashani

Any updates here? This is a pretty big problem.

Running into the same problem on OSX using node v0.6.12 and v0.6.14 with coffee 1.2.0.

@kitcambridge

So...it appears as though fs.watch is quite buggy, and is likely to remain so for some time. Any reason for not using simple polling instead?

var fs = require("fs");
function watch(name, callback) {
  (function poll(previous) {
    fs.stat(name, function (exception, stats) {
      var current;
      if (exception) {
        callback(exception);
      } else {
        if (previous && previous < (current = stats.mtime)) {
          fs.readFile(name, "utf8", function (exception, results) {
            callback(exception || null, exception ? null : results);
          });
        }
        setTimeout(poll, 250, current);
      }
    });
  })();
}
@erisdev

@kitcambridge isn't that essentially what fs.watchFile does?

@kitcambridge

@erisdiscord Yep, that's what I modeled it on (except the signature for the callback function is (error, contents); I think it's more intuitive than passing only the modification times). But the documentation states that it's also unstable, and that fs.watch should be preferred.

Edit: Of course, the implementation is only capable of watching one file at a time, but fs.readdir could be used to watch all files in a directory (as long as their names don't change, that is).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.