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

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

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but I have difficulty reading it.  Could you please provide a
> short legend?

Sorry, I forgot to do that.

The first column is the name of the test.  The 2nd lists all watched
entities mapped to symbolic names.  Further columns list the events for
specific back ends, which may refer to the same names.

Because kqueue does not support watching nonexistent files, in most
cases I did create them before starting to watch. That's why there are
usually no creation events.

In every test, I deleted all participating files as the last step.  A
`(timeout n)' event means just that: We waited for n seconds without
receiving a stopped event.

If the event lists a name anon-xyz, it means that it contained the
filename of a non-watched file.  This may signify a bug.

All test ran with the last patched I've posted applied.

>> Finally, I'm tempted to suggest to get rid of the flags argument of
>> file-notify-add-watch. 

> The flags are there for the operations where the differences matter.

When does it matter ? The callback can just ignore the events its not
interested in.  The sole advantage would be reduced complexity, but, of
course, it shouldn't be done, if this is not seen as a sufficient reason.

Also: I think in the end we want to add a layer above filenotify.el,
with the added ability of multiplexing events in a directory to multiple
watches, watching files in that directory.  The current implementation
(including the patch) returns a new descriptor for every watch.  This is
good for a low-level api, because it is easy to manage.

The downside is, that it does not scale very well.   For example every
tramp watch starts a new process and (it seems to me) every w32 watch a
new thread.

And, coming back to the original point, in this case we usually need to
watch with all flags enabled anyway.

-ap