FsEventsWatcher doesn't seem to work on OS X 10.10.5

[joelself]

I tried the example in the README.md file on current Rust (1.6.0) on my Mac (OS X version 10.10.5) and it doesn't seem to work. I tried using both the RecommendedWatcher and FsEventWatcher to watch /var/log/system.log. I tailed the file at the same time. I could see writes coming in on the tail, but I wasn't receiving any events from my watcher.

Edit: PollWatcher is working.

[passcod]

@andelf, @octplane

[joelself]

There's definitely something to do with with the file type, the way it's modified or permissions. I'm trying to tail /var/log/system.log. I can read it without elevating to root, but can't write to it without sudo. I tried another FSEvent library: https://github.com/octplane/fsevent-rust and it doesn't get notified when the file is appended, but if I do sudo touch /var/log/system.log, it registers that event. I tried rsnotify again, but it doesn't pick up on the the touches so there's still something wrong.

The file apparently has extended attributes. If I do an ls -l@ I get:

-rw-r-----@ 1 root  admin  1164847 Feb  1 16:00 system.log
    com.apple.quarantine         32 

[octplane]

I'm away from OS X until next week so I won't be able to dig further but my wild guess is that FSEvent has probably some limitation around extended attributes files.

Note that rsnotify uses my library internally on OS X so the behavior difference is probably only a configuration detail. The actual issue should probably be sent upstream for further analysis (which would start by looking at stackoverflow opinion on the subject)...

Le 1 févr. 2016 à 17:02, Joel notifications@github.com a écrit :

There's definitely something to do with with the file type, the way it's modified or permissions. I'm trying to tail /var/log/system.log. I can read it without elevating to root, but can't write to it without sudo. I tried another FSEvent library: https://github.com/octplane/fsevent-rust and it doesn't get notified when the file is appended, but if I do sudo touch /var/log/system.log, it registers that event. I tried rsnotify again, but it doesn't pick up on the the touches so there's still something wrong.

The file apparently has extended attributes. If I do an ls -l@ I get:

-rw-r-----@ 1 root admin 1164847 Feb 1 16:00 system.log
com.apple.quarantine 32
—
Reply to this email directly or view it on GitHub.

[joelself]

I removed the special attribute and it didn't change anything (for either library).

[joelself]

I wouldn't take this as very high priority. I only cared about MacOS because I was developing on a Mac. My ultimate targets are Linux and Windows. I'm just going to develop in Linux from now on.

[octplane]

After some investigation, It appears this is a (security) limitation of the FSEvent API. I suggest we close that, maybe add a note somewhere in the doc regarding the fact that the PollWatcher might work around this issue.

[passcod]

Sounds good. Can you draft something to that effect? I'll add it tonight.

[passcod]

Done in #51, may also be able to be covered in #64.

[umanwizard]

I believe the analysis in this thread to be wrong. I do not think /var/log/system.log is unreadable for security reasons; rather, I think the issue is that FSEvents only delivers file-modified events when a file handle is closed, and whatever daemon writes to that file is not closing it.

See the discussion in #240 .