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 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 ?
>
> How does inotify (and the other libraries) work in this case? Does it
> support hard links? We should not add more logic than the native
> libraries offer.

inotify seems to be inode-based, so it emits notifications independent
of the filename used.  I think that hard-links are not commonly used
under win32, but I don't know.

I we stay with string-equal, we are watching filenames, not files.
Which is probably sufficient/OK.  Maybe this should be mentioned in the
manual, I made a note of it.

>
>> + Watching a /dir/file may receive events (e.g. touch /dir) for dir.
>
> Could you pls give an example?

With inotify: 

(let ((desc (file-notify-add-watch
             "/tmp/file" '(attribute-change)
             (lambda (_) (cl-assert nil)))))
  (unwind-protect
      (progn
        (shell-command "touch /tmp")
        (sit-for 3))
    (file-notify-rm-watch desc)))

>> + Why the seemingly arbitrary exclusion of backup-files in
>>   file-notify-callback ?  What if someone wants to track the creation of
>>   said files ?
>
> When a file under supervision is renamed during backup, the supervision
> might be stopped. This case must be handled.

Yes, I see.

>> + 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.
>
> Why don't we know what kqueue does?

This:

    (if handler
        ;; A file name handler could exist even if there is no local
        ;; file notification support.
        (setq desc (funcall
                    handler 'file-notify-add-watch
                    ;; kqueue does not report file changes in
                    ;; directory monitor.  So we must watch the file
                    ;; itself.
                    (if (eq file-notify--library 'kqueue) file dir)
                    flags callback))


Why should we assume that handler is somehow related to kqueue ? I think
its just a copy and paste error.  The comment should be moved to the
actual library call below this.

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.

Thanks for you response,
-ap