-
Notifications
You must be signed in to change notification settings - Fork 247
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
Feature request: Reverse symlink lookup #279
Labels
✨ Feature
Adds a new feature
Comments
This was referenced Nov 27, 2014
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, Listen follows directory symlinks to watch the "real" directories.
This feature would enable listen to report changes as if it the symlinked directories were real directories.
e.g. given the directories and symlinks:
When watching simultaneously
foo
andbar
andbaz
, a change in any of those should result in changes reported in all 3 "directories" (even though it physically happens only infoo
).This would allow apps such as Guard to "watch"
bar
and receive events relative tobar
so symlinked directories would be "transparent" (regardless of how the backend treats them).E.g. if
baz
is watched, andfoo/file.txt
changes, then Listen should only reportbaz/file.txt
as changed.How to implement
Just as Listen has a record of files and their attributes, it would need a record of symlinks relative to which it could "generate" the events (based on the real event).
Current behavior
This is "partially implemented" (incorrectly), by reporting files as relative to the watched directory, which means potentially reporting non-existing paths as changed (test cases are needed).
Pitfalls
This could obviously be slow in some scenarios, e.g. an
:absolute_events
option could skip this resolution.The text was updated successfully, but these errors were encountered: