Feature request: Listen could detect changes in symlinked files

[e2]

Listen follows symlinked directories to watch the original directories, though symlinked files obviously don't trigger changes on the directories they are in.

Example: if foo/file.txt is symlinked to bar/original.txt, Listen could detect this and quietly add bar as a watched dir, but report foo/file.txt as changed (and ignore any other changes in bar).

(Polling already does this, because it uses 'lstat' and relies completely on Record and scans the whole watched tree anyway at regular time intervals.)

This feature is not really needed, but it would be "proof" that the architecture of Listen is sound and that it "meets user expectations" (however technically unrealistic or self-conflicting they usually are).

[akerbos]

This feature is not really needed

I respectfully disagree and am glad that you consider implementing this!

[e2]

I believe this is a Linux-only feature. Polling scans everything, and OSX support is basically the same, except it scans less directories and when actual (but unknown) events occur.

This is a problem, because Listen is almost pointless on Linux, where lots of directories can be cheaply and effectively scanned. Listen is just pure overhead on Linux, while every bit of Listen is essential for the other adapters.

I don't use OSX or Windows, and implementing anything "smart" in Listen means potentially breaking those platforms.

"Adding" something while not breaking something is the biggest challenge in Listen.

So I'll consider implementing this sooner rather than later - and just for Linux (as a "if Linux/inotify" thing).

[akerbos]

If Listen is "pure overhead" on Linux, what do you recommend? rb-inotify directly or something different?

[e2]

It depends on what you need and if you're using Listen directly or not. "Pure overhead" maybe isn't fair.

Here are the "bonuses" of using Listen under Linux:

• it's used by other apps (Sass, Vagrant, Guard, Spring, etc.), and the overhead is acceptable, given portability. (You can run with LISTEN_GEM_DEBUGGING=2 to see if you're actually paying a price for this overhead or not.
• smart editor support (translating move_to, and move_from into changes)
• built in ignore rules

and most importantly - waiting for activity to "stop" and then merging chunks of changes into single events (important for editing) - instead of getting the callback immediately called whenever "anything" changes.