That's not true.  Users watch inodes, not files (this is true for both
inotify and fanotify).  Give it a try, it works.

-Eric

--

[ message continues ]

debian-i386:~/tmp# touch a
debian-i386:~/tmp# ../fanotify a &
debian-i386:~/tmp# link a b
debian-i386:~/tmp# ls -li
total 0
3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 a
3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 b
debian-i386:~/tmp# echo 123 > b
/root/tmp/b: pid=2143 mask = 20 open
/root/tmp/b: pid=2143 mask = a modify 0 - 4 close(writable)  0 - 4

Am I doing something wrong? Same thing happens if I watch the mount point.
--

[ message continues ]

Maybe I don't understand the problem, you watched the inode behind A.
You made changes accessing this inode via B, you got notification about
those changes.  Isn't that what you wanted?

--

[ message continues ]

I'd expect to get two notifications in this case. Might not be a
problem when you are watching individual files, but there is no clear
way to get all the modified files, if you are watching a mount point.
--

[ message continues ]

Ah, you were hoping for 4 events.  Yeah, not possible.  You get notified
when the inode changes, which way you get notified is up to the kernel
and we leave it as an (impossible) exercise to userspace to map hard
linked inodes back together   :)


--

[ message continues ]

Yeah, I see now, it's impossible to get all the files linking to an
inode even from the kernel space without scanning the fs. Thanks for
the clarification.
--

[ message continues ]