bug#35418: [PATCH] Don't poll auto-revert files that use notification

[Mattias Engdegård]

29 apr. 2019 kl. 14.26 skrev Michael Albinus <michael.albinus@gmx.de>:
> 
> You don't know first hand, which buffers contain the same file hard
> linked together. This can be determined only via the inode and device
> numbers; something we don't apply yet.
> 
> How do you know otherwise, that "/tmp/foo" and "/tmp/bar" are the same,
> visited in different buffers?

Thanks, I think I understand what you are concerned about now.
It seems to work just as we expect it to (at least in kqueue and inotify):

A file has three hard links, /dir1/a, /dir1/b and /dir2/c. Then:

- A watch set on /dir1/a will report changes made to the file via any of the 
three links (kqueue, inotify).
- A watch set on /dir1 will report changes made to the file via /dir1/a and 
/dir1/b, but not /dir2/c (inotify).

Since filenotify would use /dir1 to watch /dir1/a with inotify, but /dir1/a 
with kqueue, the behaviour differs.
We could work around the problem by setting watches on files directly with 
inotify, but it's not worth the trouble or the other drawbacks (as mentioned 
earlier) for such an uncommon case.

> As Tramp maintainer, I always set `auto-revert-remote-files' to t :-)
> So I care.

Right, so I suppose a user like you would either:

(a) not set `auto-revert-always-poll' to nil
(b) trust remote file notification to work well enough, and if it fails, it's 
not a disaster (no data lost)
(c) add a pattern to `auto-revert-notify-exclude-dir-regexp' to disable 
particularly unreliable notifications

which sounds acceptable.