notify
notify copied to clipboard
Hard-linked files return the same path regardless of path modified (linux)
System details
- OS/Platform name and version:
Linux 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
- Rust version (if building from source):
rustc 1.41.0 (5e1a79984 2020-01-27)
- Notify version (or commit hash if building from git):
commit eed64ac9088ec1aab5c4710ef7232f0fbee49e0a
Date: Fri Feb 7 19:40:35 2020 +0100
- Filesystem type and options:
ext4 rw,user,exec 0 0
- On Linux: Kernel version:
4.15.0-74-generic
- If you're running as a privileged user (root, System): no
- If you're running in a container, details on the runtime and overlay: no
- If you're running in a VM, details on the hypervisor: no
What you did (as detailed as you can)
When hard-linking one file to another, i.e. touch test && ln test test_link
, and placing a monitor on the file, the last file being registered is always returned regardless of which is modified.
What you expected
The correct file path is returned in the list of files based on the path modified.
What happened
Only the last registered path is returned. I did some investigation. I think this is a limitation of inotify
in Linux. Performing the same test on macOS provided the expected results (I
m pretty sure). After investigating it appears that both hard-linked files when registered with return the same WatchDescriptor::id
. This results in the watches (path -> WatchDescriptor) and then paths (WatchDescriptor -> Path) overwriting each other. This matches the behavior I've noticed, where when an event comes into EventLoop::handle_inotify
only the most recently registered file path is notified.
I initially started down a path to experiment with changing the EventLoop::paths
from HashMap<WatchDescriptor, PathBuf>
to HashMap<WatchDescriptor, Vec<PathBuf>>
but this creates confusing output in multi-path events, such as rename. Has anyone else seen this? Any thoughts on a path forward?