notify
                                
                                 notify copied to clipboard
                                
                                    notify copied to clipboard
                            
                            
                            
                        Feature request: Allow user-defined filtering before setting a watch
#255 is related but is NOT the same thing.
I have a use-case in which I want to watch my entire $HOME. However, due to WINE prefixes and other circumstances, it turns out I have a bunch of symlinks into / by accident. This is causing the inotify watcher to recurse through the entire directory tree and error out when it can't set a watch on something owned by root and not world-readable. It'd be nice to be able to filter out symlinks that specifically go to /.
Beyond this, it would be nice to be able to make something equivalent to ignore to ex. not open watches on a node_modules folder or other ignored files.
If this is worth adding, I'll try to put together a PR for this.
Hi, I like the idea of using the ignore crate, though maybe it's also worth to add some option of disabling symlinks? Would need some investigation how easy that could be implemented. At best we can find a solution that does not take much overhead and makes sense across systems (as symlinks on windows are kinda irrelevant ?).
Regarding ignore: I'm not sure if we want to introduce this as a direct dependency but I'm also on the fence how we could implement this in the most user friendly way without adding another callback to allow setting your own filter implementation.
One reason is that I'd only introduce this ignore api as an feature, though it's probably something many people might want. On the other side I personally dislike adding more callbacks as we really don't want to block in the core watcher implementation.
Thanks for the response!
[...]though maybe it's also worth to add some option of disabling symlinks?
The specific use-case I'm having can't just blanket-ignore symlinks, unfortunately. Some of the directories in my $HOME that I'd want to watch are symlinks to other drives (think ex. games being installed on an SSD while $HOME is an HDD), hence why I'd prefer more-specific filtering ("don't follow a symlink to /, but follow it to these other directories").
Regarding ignore[...]
A large part of why I'm interested in using ignore is because it allows a parallel walk of the target directory, and I'm using it in other parts of my code already. It looks like you can disable the standard filters which I imagine should be enough for not causing compatibility issues? Would need testing for sure. ignore also allows custom filtering of directories -- which could be used for preventing my specific use-case -- and blanket-disabling of symlink following which would also fix #255.
I understand not really wanting to add another dependency / callback / etc. for this, and that's fine with me ^^ I'm mostly just trying to avoid reimplementing notify on top of ignore myself, tho I don't mind doing so if it comes to it.
In the short term, I can likely handle this via traversing the directory tree with ignore and setting non-recursive watches myself.
The specific use-case I'm having can't just blanket-ignore symlinks, unfortunately. Some of the directories in my
$HOMEthat I'd want to watch are symlinks to other drives (think ex. games being installed on an SSD while$HOMEis an HDD), hence why I'd prefer more-specific filtering ("don't follow a symlink to/, but follow it to these other directories").
This would be possible by simply filtering what to watch instead of filtering which symlinks to follow, wouldn't it ? So we don't need another filtering API besides the ignore filter.
Yes! Filtering what to watch would solve the entirety of my current issues.
Ok if you want you can add this as a PR against main so it'll be added to an upcoming v5-pre release.
Otherwise I'll probably have to wait after #288 and #286 on my side to make myself a mental model of how I'd add this API and add it for every OS (which is the real meat of that PR).
Also I'd probably want to add a "don't follow symlinks at all" option, which could come in handy.
Oh an if you want to do this PR by yourself you could feature-gate a ignore dependency or add an example how you can utilize this with the new API. (possibly using a callback and stuffing ignore inside?)
Hmm, after rethinking my wants, I think I really just need a "don't follow symlinks" in the end. I also couldn't come up with a good API that actually ended up working here :< I'll leave this open in case there's interest in implementing this in the future.