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.

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

Open
e2 opened this issue Nov 25, 2014 · 0 comments
Open

Feature request: Reverse symlink lookup #279

e2 opened this issue Nov 25, 2014 · 0 comments
Labels
✨ Feature Adds a new feature

Comments

@e2
Copy link
Contributor

e2 commented Nov 25, 2014

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:

mkdir foo
ln -s foo bar  # bar -> foo
ln -s foo baz  # baz -> foo

When watching simultaneously foo and bar and baz, a change in any of those should result in changes reported in all 3 "directories" (even though it physically happens only in foo).

This would allow apps such as Guard to "watch" bar and receive events relative to bar so symlinked directories would be "transparent" (regardless of how the backend treats them).

E.g. if baz is watched, and foo/file.txt changes, then Listen should only report baz/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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ Feature Adds a new feature
Projects
None yet
Development

No branches or pull requests

1 participant