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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

> If you look at bug reports and discussions around the time this
> comment was written, you will find the descriptions of the use cases
> that caused this design.  AFAIR, the main problem was with inotify,
> not with w32notify.

Inotify didn't work on mounted directories. I don't know whether this
has improved.

Gfile is agnostic to file systems being mounted or not. If inotify (used
internally) doesn't work, it uses polling. However, gfile has shown
instability; that's why it isn't the first choice anymore.

I don't remember the behavior of kqueue.

>> However, isn't this what `auto-revert-notify-exclude-dir-regexp' is
>> for? I'm not familiar with the way Emacs is used on Windows, but
>> would adding something like
>>
>>  (rx bos
>>      (or "\\\\" "//")
>>      (one-or-more (not (any "/:\\")))
>>      (any "/\\"))
>>
>> to `auto-revert-notify-exclude-dir-regexp' be a good start?
>
> If you imply that Samba drives can be identified by the syntax of the
> file name alone, then I don't think this is a valid assumption.  A
> certain drive letter can be mapped to a Samba volume, and we can never
> know that by looking just at the file name.
>
> More generally, auto-revert-notify-exclude-dir-regexp is for any
> situation where a filesystem doesn't cause notifications.  You will
> find caveats about such issues in the documentation of every
> notification system we support.

The default value of `auto-revert-notify-exclude-dir-regexp' tries to
identify common mount points, like /mnt or /media and alike. But like Eli
said already for Samba mounts, we cannot detect all of them by their
name.

What might be an alternative is to let the user decide. If we provide a
user option `auto-revert-dont-poll', a user could set it to t, and would
live with the consequences. If she tries to enable autorevert for a
mounted directory, which is not covered by file notifications, she might
be surprised.

> Thanks.

Best regards, Michael.