You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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: