bug#26126: 26.0.50; file-notify-rm-watch removes arbitrary watches

[Andreas Politz <politza@hochschule-trier.de>]

Michael Albinus <michael.albinus@gmx.de> writes:

>>>> + Watching a /dir/file may receive events (e.g. touch /dir) for dir.

> Yes, I remember. For all backends except kqueue, we watch the
> directory. This is intended.
>

Sure, the back-ends mostly watch directories, except for kqueue.  But is
this behavior also intended to be propagated to the clients of
filenotify.el ?

>>>> + Why is the existence of kqueue checked for the handler in
>>>>   file-notify-add-watch ? After all we don't know how this handler will
>>>>   operate.

>> I also wonder, if the passed argument should not always be the filename
>> for which the watch was requested, as opposed to its directory.  After
>> all we should not make assumptions about the abilities of the underlying
>> mechanism.  For example it could work similar to kqueue, i.e. with an
>> inability to watch directories.
>
> We've discussed this years ago, maybe you find it in the archives. There
> are problems when you watch only the file. This doesn't work for example
> when you want to watch a file which does not exist yet. Or which
> disappears, and reappears.
>
> The agreement was to watch the upper directory. This works for all
> backends except kqueue.

Sorry, for not being clear: I was exclusively talking about
file-name-handler here.  Passing the intended filename is more general
then passing the directory only.  Think of some program foonotify, which
is similarly limited like kqueue.  Granted, this scenario probably won't
come up very soon.

-ap