-
Notifications
You must be signed in to change notification settings - Fork 37
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.
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
Support for symlinked directories #19
Comments
The symlink itself is a file that hasn't changed, so no. I realize this can be counter-intuitive from an interface standpoint... You could also watch the projects directory itself. An additional tricky detail is that the fsevents api resolves all paths internally. So if you tried to directly watch In short, this is confusing but "correct". |
...I could see outputting a warning in scenarios like this as a potentially good idea, but I don't think that rb-fsevent would be the right place to put such a warning. It seems like it would make more sense one level up, in an application or library that makes use of rb-fsevent and potentially other backends (like rb-inotify) that would have the same issue. This is especially true given that a polling based backend could potentially see the symlink as a directory and behave exactly how you would have expected. Is it acceptable to close this issue? If you have any ideas on how to make these "works with polling" style bugs less frustrating I'd love to hear them and keep this ticket open. |
How would I work around this issue? I have a local development environment with various symlinked directories that I'd like to monitor for changes. |
Imagine the following directories structure:
If I do:
And I change the /home/projects/dir_b/dir_b_file, isn't a callback supposed to run?
The text was updated successfully, but these errors were encountered: