changes in regular files pointed by symbolic links are not tracked

[morenol]

System details

• OS/Platform name and version:
  Ubuntu 20.04
• Rust version (if building from source): rustc --version:
  rustc 1.58.0 (02072b482 2022-01-11)
• Notify version (or commit hash if building from git):
  0faae41

I am trying to use notify to keep track of changes in files but they are symlinks to regular files. I noticed that when using symlinks to directories everything works as expected since walkdir iterates follows the symlinks and call add_watch on them but the symbolic links to files are being ignored and in any place of the code we are calling add_watch.

What you did (as detailed as you can)

I have this:

---> README.md
---> a.d/
---------> a.txt
----------> b (-> ../README.md)

And I used this crate to track events on a/. If I change the README.md content I dont get any events

What you expected

I would expect that any file that is linked by a symlink should be tracked

What happened

I dont get any events on files pointed by symlinks

I think that we could solve this issue if we change filter_dir to also allow symlinks when they point to regular files

notify/src/inotify.rs

Line 560 in 0faae41

fn filter_dir(e: walkdir::Result<walkdir::DirEntry>) -> Option<walkdir::DirEntry> {

[0xpr03]

Duplicate of #255

[morenol]

I'm sorry but I think that these two issues are a little bit different, using the workaround described in that PR didn't work for this issue. I think the other issue is more about trying to watch dead symlinks.

In this case, IN_DONT_FOLLOW is not needed. For now, I had to do this morenol@93a9bd1

[0xpr03]

Hm yeah, so the problem is that we'd need an option whether to resolve symlinks if I'm following this correctly.
I've added one comment to your linked commit because I couldn't see why it was necessary.

[morenol]

Yes, so basically if I have a folder

/var/log/container/

with the logs off all the containers:

etcd-minikube_kube-system_etcd-5290828f62a8e91dae0f6a7394b142948fb844e8f23610661ddbfa5d9f4e3fbc.log
kube-apiserver-minikube_kube-system_kube-apiserver-edcbf4d2fb2903b09097ccb25606e7aca9abd5b940796168fa9ba7eac23ce34f.log
kube-controller-manager-minikube_kube-system_kube-controller-manager-01838fc9c5b9deafbd3bcae75eff0af4e55fc19b6feaad1e8dad994091f31d8c.log
kube-proxy-fks8n_kube-system_kube-proxy-56753f78ed16e3c6853ea5b6cc87252279497c814c71d9b2929e68050c1fa755.log
kube-scheduler-minikube_kube-system_kube-scheduler-d46dd038c8243641e83d027876775678b2a9663e9e18ceda53adbceca327dc7a.log

But they are actually symlinks to the logs from the containers:

lrwxrwxrwx    1 root     root           121 Jan 14 14:18 kube-controller-manager-minikube_kube-system_kube-controller-manager-01838fc9c5b9deafbd3bcae75eff0af4e55fc19b6feaad1e8dad994091f31d8c.log -> /var/log/pods/kube-system_kube-controller-manager-minikube_a5754fbaabd2854e0e0cdce8400679ea/kube-controller-manager/0.log

If I watch on /var/log/container/ I am not getting events when the file that is pointed by that symlink is modified

[colemickens]

Thanks to those working on and considering this. Notable to me anyway, is that one side-impact of this is that any application using this library to auto-reload on config changes fails to work properly with Nix/NixOS/Home-Manager and require special application level workarounds. (In some cases, applications don't have an alternative).