Stops reacting to file changes after the first time

[alexgorbatchev]

i'm on OSX 10.7.4 with node 0.8.8 using watch v0.1.4 and here's my grunt file

module.exports = function(grunt)
{
    grunt.loadNpmTasks('grunt-typescript');
    grunt.loadNpmTasks('grunt-contrib-less');
    grunt.loadNpmTasks('grunt-contrib-copy');
    grunt.loadNpmTasks('grunt-contrib-watch'); 

    grunt.initConfig({
        typescript : {
            base : {
                src     : [ 'src/**/*.ts' ],
                dest    : 'build',
                options : {
                    module    : 'commonjs', // or commonjs
                    target    : 'es5', // or es3
                    base_path : 'src/'
                }
            }
        },

        less : {
            development : {
                options : {
                    paths : [ 'src/less' ],
                    compress : false
                },
                files : {
                    'build/public/css/main.css' : 'src/less/main.less'
                }
            }
        },

        copy : {
            public : {
                files : {
                    'build/public/': 'src/public/**'
                }
            },
            views : {
                files : {
                    'build/views/': 'src/views/**'
                }
            }
        },

        watch : {
            typescript : {
                files : 'src/**/*.ts',
                tasks : [ 'typescript' ]
            },
            less : {
                files : 'src/less/**',
                tasks : [ 'less' ]
            },
            public : {
                files : 'src/public/**',
                tasks : [ 'copy:public' ]
            }
        }
    });

    grunt.registerTask('default', 'copy less typescript');
};

i run grunt watch and it works the first time i save the file and then no more... am i doing something wrong?

[shama]

Your config looks good. Can you update to the latest node v0.8.14? v0.8.8/9 has a watch issue: nodejs/node-v0.x-archive#3997 Otherwise set the option forceWatchMethod: 'old' to use the older/slower watch method if you can't update atm.

[aoberoi]

I'm having the same problem even after updating to node 0.8.14. Any thoughts?

BTW. I'm using forceWatchMethod: false successfully, but it is noticeably slow. Would love to speed things up.

[darky]

For me forceWatchMethod: 'old' work only
I hope forceWatchMethod: 'new' will work soon =))

[shama]

Hopefully I can help you guys get it working. I'm having some trouble duplicating the issue on node v0.8.14 on OSX 10.6, Windows 7 and Ubuntu 12.04.

forceWatchMethod: false is the default. Node has two watch methods: fs.watch aka new (faster but less compatible) and fs.watchFile aka old (slower but more compatible). By default the watch will use both methods. Then which ever one responds first will be the method used in subsequent actions.

@aoberoi and @Darrrk Which OS and version are you using? So I can try to duplicate to see if I can find the issue. Thanks!

[aoberoi]

@shama thanks for responding so promptly :)

I'm using OS X 10.8.2. Do you think it would help if I download the node source and run the test suite? It looks like theres one for watch at https://github.com/joyent/node/blob/master/test/simple/test-fs-watch.js

[shama]

Thanks @aoberoi I think that would be very helpful. I hope it's not an issue with OSX 10.7+ as I only have access to a OSX 10.6 machine atm. I'll bother some co-workers this week to see about testing on OSX 10.8 or 10.7 as well.

[shama]

This might be related: nodejs/node-v0.x-archive#3343

[aoberoi]

The test suite for v0.8.14 passes on my machine.

From the issue you refereced, it looks like we shouldn't hope for a fix until version > 0.9 is stable? That would stink.

[adambiggs]

+1

I'm on node v0.8.15 / OSX 10.8.2 and experiencing the same thing. Only works when using forceWatchMethod: 'old'.

[rgaskill]

This issue is dependent on the editor being used to cause the change. For example if I edit a watched file with vim or Intellij it will work the fist time but not for any changes after that. If I use sublime it will work fine for each change (node v0.8.15 OSX 10.8.2). The difference between the editors appears to be vim and intellij will renames the original file unlike sublime which which just changes the file. You can see this in the the events being fired from the fs.watch. I don't know the details of the editor implementations, but I assume vim and intellij renames the original file being watched and all future edits are happening in a new file that isn't being watched.

EDIT:
If I turn off "safe write" in intellij the updates work fine because isn't making a copy of the file on each save it is actually changing the file being watched.

[alexgorbatchev]

I'm using MacVim, @rgaskill description sounds like the right idea to me. Perhaps we should add "vim" mode where it watches for files being moved around?

[adambiggs]

I'm using Coda 2 with the same symptoms as @rgaskill

[shama]

You can add set nowritebackup to your ~/.vimrc to disable that "feature".

Quite annoying because technically the watch is doing what it is supposed to. When the editor deletes the file, it stops watching it.

Adding a safe write option to gaze sounds like a good idea as this seems to be a common file handling technique for editors. Take a look at this issue on gaze as @sebv might already have a solution.

[rgaskill]

I have a rough hack at 214c326f54. It will handle the rename caused by editing, but I don't think it will handle an actual rename correctly.

[shama]

Here is a test to simulate a safe write event: shama/gaze@8f6c61e

[rgaskill]

@shama I have a fix here rgaskill/gaze@d021f4f9 that will pass your test. I also fixed what appeared to be a bug in the _isMatch method and _initWatched method rgaskill/gaze@95d42e5.

There still appears to be some leaking file handles though. When I run all the tests together I get:

 Fatal error: EMFILE, too many open files

I get this error in the master branch as well. I will continue to look into the "too many open files" issue, but I thought you might want to comment on what I have done so far.

[shama]

@rgaskill Nice! I'll give that a go. Want to open a PR?

too many open files is from your system's ulimit open files setting. You can temporarily increase it before running the tests with ulimit -n 10480.

[rgaskill]

Sure no problem.

PR shama/gaze#6

[drawveloper]

Running node 0.8.15 on Ubuntu 12.10, also getting this very annoying issue. It actually happened to me while working on another lib of mine, remote.

I fixed it by using this:

fs.watchFile options.file, { persistent: true, interval: 1000 }, (curr, prev) ->
  unless curr.size is prev.size and curr.mtime.getTime() is prev.mtime.getTime()
    console.log "Config file changed - updating options."
    readOptions(options.file)  

Which is probably the same code being used when using forceWatchMethod: 'old'

My opinion is: while the node API isnt stable, simply use a smaller polling value. 1000 is ok. The default 5000 is sluggish.

[shama]

@gadr90 Yep that is the same as forceWatchMethod: 'old' but the default here is 100ms.

[drawveloper]

Oh, cool. Strangely feels slower, though.

On Tue, Dec 11, 2012 at 10:51 PM, Kyle Robinson Young <
notifications@github.com> wrote:

@gadr90 https://github.com/gadr90 Yep that is the same as forceWatchMethod:
'old' but the default here is 100mshttps://github.com/shama/gaze/blob/master/lib/gaze.js#L67
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-11272057.

[shama]

@gadr90 Looks like I was wrong. It was supposed to be 100ms but @rgaskill identified a bug where it was actually 5000. Fixes coming down the pipeline from shama/gaze#9 soon.

[shama]

Fixed with 808d4a3 and available in v0.2.0a.