Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OSX - Watching 3 or more directories fails #23

Closed
compressed opened this issue Jul 25, 2015 · 8 comments
Closed

OSX - Watching 3 or more directories fails #23

compressed opened this issue Jul 25, 2015 · 8 comments
Labels
A-bug os-mac

Comments

@compressed
Copy link

Hi,
I'm running OSX 10.10.4 and was trying to use the cargo watch tool, however it wasn't working. It seemed whenever the "benches" watch was added, cargo watch wouldn't watch anything...

Digging further, it seems something goes awry when adding the third watch. For the prior two watches, this condition is met (fsevent.rs line 62):

    if !self.is_running() {
      return;
    }

On the third try however, that condition isn't met, and it makes its way all the way to this match (fsevent.rs line 78):

      match context_info.done.recv() {
        Ok(()) => (),
        Err(_) => panic!("the runloop may not be finished!"),
      }

And never makes it past there...

Let me know if you need more information.

Also, if I try running cargo test, it fails:

~/rsnotify git:master ❯❯❯ cargo test                                                                                                                                                                                            ⏎
     Running target/debug/notify-a00f19333567126a

running 1 test
test fsevent::test_fsevent_watcher_drop ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/notify-b65501780e7463a9

running 7 tests
test new_null ... ok
test new_fsevent ... ok
test new_recommended ... ok
test new_poll ... ok
test watch_dir_recommended ... FAILED
test watch_single_file_poll ... ok
test watch_single_file_recommended ... FAILED

failures:

---- watch_dir_recommended stdout ----
    thread 'watch_dir_recommended' panicked at 'assertion failed: `(left == right)` (left: `"/private/var/folders/b5/yh22bw792yj4n0q68vckrbjw0000gn/T/dir.KTsLmVgBAqyo"`, right: `"/var/folders/b5/yh22bw792yj4n0q68vckrbjw0000gn/T/dir.KTsLmVgBAqyo/dir1.W4y90yVhB8oP/dir11.EPrh1Cq6JFaE/.9ZIU5fW5tHKo"`)', tests/notify.rs:16


---- watch_single_file_recommended stdout ----
    thread 'watch_single_file_recommended' panicked at 'assertion failed: `(left == right)` (left: `"/private/var/folders/b5/yh22bw792yj4n0q68vckrbjw0000gn/T/.D36zoPQgBQr0"`, right: `"/var/folders/b5/yh22bw792yj4n0q68vckrbjw0000gn/T/.D36zoPQgBQr0"`)', tests/notify.rs:16



failures:
    watch_dir_recommended
    watch_single_file_recommended

test result: FAILED. 5 passed; 2 failed; 0 ignored; 0 measured

thread '<main>' panicked at 'Some tests failed', /Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/src/libtest/lib.rs:255
@passcod
Copy link
Member

passcod commented Jul 25, 2015

Any ideas, @octplane?

@jakerr
Copy link

jakerr commented Aug 29, 2015

The test failure seems to be because fsevent-rust resolves symlinks here in cf::str_path_to_cfstring_ref. Then the test asserts it got an event on /var/folders... but its event is on /private/var/folders... this is due to the fact that /var is a symlink to /private/var on OS X

I'm not sure if the resolution of symlinks at that place is expected or not. If it is then the tests can be fixed by resolving the symlink before asserting.

@jakerr
Copy link

jakerr commented Aug 29, 2015

Oops my comment may be a bit misleading. While it is an issue it's not the issue as you can see the directory events expected in watch_dir_recommended are even out of order.

@compressed compressed changed the title OSX - Watching more than 3 directories fails OSX - Watching 3 or more directories fails Aug 29, 2015
@passcod
Copy link
Member

passcod commented Aug 29, 2015

There's an issue open for symlinks iirc. On my phone, can't check.

On Sat, 29 Aug 2015 16:21 Jake Kerr notifications@github.com wrote:

Oops my comment may be a bit misleading. While it is an issue it's not
the issue as you can see the directory events expected in
watch_dir_recommended are even out of order.

—
Reply to this email directly or view it on GitHub
#23 (comment).

@octplane
Copy link
Contributor

Oops, didn't receive any notification about this bug until yesterday. Sorry for the delay, I'll look into it quickly...

@octplane
Copy link
Contributor

The runloop stuff is a bit curious. I have made my binding testable and I does not fail with three folder to listen. It does none of the stop/start of rsnotify https://github.com/passcod/rsnotify/blob/master/src/fsevent.rs#L223 (which I'm not sure it the right way to do)

However, the FSEvent API resolves all symlinks when calling back its listener and I suppose this behavior is not compatible with the other bindings.

Also, some events sent by the FSEvent API are from the 'past' (this is another very troublesome issue that might or might not be due the API itself...).

All these difficulties will make testing this not cool :) But I'm on it :D

@octplane octplane mentioned this issue Aug 31, 2015
Merged
@passcod
Copy link
Member

passcod commented Feb 1, 2016

@compressed, etc Does this still occur?

@passcod
Copy link
Member

passcod commented May 2, 2016

Closing. Comment/reopen if it's still occurring.

@passcod passcod closed this as completed May 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-bug os-mac
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@octplane @compressed @passcod @jakerr