GNU bug report logs - #26126
26.0.50; file-notify-rm-watch removes arbitrary watches

Previous Next

Full log

View this message in rfc822 format

From: Andreas Politz <politza <at> hochschule-trier.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 26126 <at> debbugs.gnu.org
Subject: bug#26126: 26.0.50; file-notify-rm-watch removes arbitrary watches
Date: Sat, 18 Mar 2017 14:32:08 +0100

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

> Andreas Politz <politza <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.