Doesn't ever call the command #7

wilsonandcompany opened this Issue Apr 1, 2014 · 7 comments


None yet

6 participants


Can't get it to work. OSX 10.8.3

callm0690:~ wleong$ auto_rsync test vmbox:/data
Watching test
Path is /Users/wleong/test
Watching /Users/wleong/test
Change 14422625 in /Users/wleong/test/.Gemfile.swpx, flags 66304
Change 14422634 in /Users/wleong/test/.Gemfile.swp, flags 82688
Change 14422722 in /Users/wleong/test/4913, flags 82688
Change 14422726 in /Users/wleong/test/Gemfile~, flags 67584
Change 14422729 in /Users/wleong/test/Gemfile, flags 67840
Change 14422735 in /Users/wleong/test/Gemfile, flags 88320
Change 14422738 in /Users/wleong/test/Gemfile~, flags 68096
Change 14422765 in /Users/wleong/test/4913, flags 82688
Change 14422768 in /Users/wleong/test/Gemfile, flags 67584
Change 14422769 in /Users/wleong/test/Gemfile~, flags 67584
Change 14422772 in /Users/wleong/test/Gemfile, flags 67840
Change 14422778 in /Users/wleong/test/Gemfile, flags 88320
Change 14422781 in /Users/wleong/test/Gemfile~, flags 68096
Change 14422933 in /Users/wleong/test/4913, flags 82688
Change 14422946 in /Users/wleong/test/Gemfile, flags 88320
Change 14422949 in /Users/wleong/test/Gemfile~, flags 68096
Change 14423001 in /Users/wleong/test/.Gemfile.swp, flags 69632
Change 14423004 in /Users/wleong/test/.Gemfile.swp, flags 70144
Change 14423016 in /Users/wleong/test/.git/index.lock, flags 65792
Change 14423019 in /Users/wleong/test/.git/index.lock, flags 69888
Change 14423022 in /Users/wleong/test/.git/index.lock, flags 71936
Change 14423024 in /Users/wleong/test/.git/index, flags 67584
ioga commented May 17, 2014

Same here. notifywait doesn't exit on change.


Same here.

ggreer commented Apr 10, 2015

I can reproduce this, but I'm very confused by this behavior. There is an exit(0) immediately after the printf():

Newer versions of OS X must fork() or something when the FS watch loop is created. I'll play around with it more to see if I can fix the bug.

ggreer commented Apr 19, 2015

Try master now. It might be fixed by #11.

easel commented May 19, 2015

I'm seeing this behavior, unfortunately. It starts and continues reporting on the stream without exiting.

@easel easel added a commit to easel/fsevents-tools that referenced this issue May 19, 2015
@easel easel Allow exit if no files are being skipped
Fixes #7
easel commented May 19, 2015

The fix in PR#12 is working for me. I tried a couple different sets of command line arguments but haven't tested extensively. I believe the issue was simply a logic error -- if the user isn't skipping any files (for instance, if they ran notifywait .), we'd never have files to match (and exit) and we'd never mark anything as ignored so we'd never exit because count would always be > 0.

Unfortunately, I don't know what "cram" is and have burned the time I have to spend right now so I haven't updated the tests.

The biggest remaining (potential) issue to me is whether or not the FSEvents stream is being cleaned up automatically. Theoretically the OSX guys should handle it properly on exit(0), but I could easily see that not being the case.

ziedzic commented Nov 7, 2015


@ggreer ggreer closed this in #12 Dec 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment