notify

notify copied to clipboard

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): 0faae4139f4aff5f2a07c7e2d8c41ee181367183

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

https://github.com/notify-rs/notify/blob/0faae4139f4aff5f2a07c7e2d8c41ee181367183/src/inotify.rs#L560

Duplicate of #255

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 https://github.com/morenol/notify/commit/93a9bd1a318a1e0602875c65c0c22b5968ac725b

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.

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

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).