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

[Andreas Politz]

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

> Andreas Politz <politza@hochschule-trier.de> writes:
>> A different question is, whether file-notify-add-watch should behave
>> like add-hook [...]
>
> I believe adding the *same* function twice for the same file/directory
> doesn't make sense. Maybe we should document this in the Elisp manual,
> and test it also in `file-notify-test01-add-watch'.

There is a check for this in file-notify-add-watch:

    (unless (member entry (cdr registered))
      (puthash desc ... file-notify-descriptors))

So, I should probably stay this way. (Even so, one might favor it being
differently, because file-notify-add-watch returns a cookie and thus has
more like a transactional semantics, for lack of a better word).

I took a deeper look filenotify.el and found some problems/have some
further questions. Note that I use inotify.

+ A watched hard-link for some other file may not receive its events,
  due to string-equal being used for file-comparisons.  Shouldn't
  file-equal be used instead ?

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

+ Why the seemingly arbitrary exclusion of backup-files in
  file-notify-callback ?  What if someone wants to track the creation of
  said files ?

+ 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.

-ap