bug#21435: 25.0.50; file-notify has problems after renames

[Michael Albinus]

Tassilo Horn <tsdh@gnu.org> writes:

Hi Tassilo,

> Ok, I gave it a whirl and now the `file-notify--test-event-handler' also
> records all events in a new variable `file-notify--test-events' for
> later analysis.  `file-notify-test02-events' now uses that feature to
> check if the received events are the expected ones in the expected
> order.
>
> That already revealed two problems:
>
>   1. Now `file-notify-test02-events-remote' fails because after every
>      expected `changed' event an additional `attribute-changed' event is
>      received.  This is wrong because when adding the watch, only
>      '(change) is given as FLAGS argument, not '(change
>      attribute-change).

I'll contact the Tramp maintainer about :-)

>   2. When I change the watch FLAGS to '(change attribute-change), there
>      are still no attribute-changed events received in the local case.

attribute-change happens when you change file permissions, or
modification time w/o changing the file contents. Something like

--8<---------------cut here---------------start------------->8---
(progn
  (require 'filenotify)
  (defalias 'myhandler 'ignore)
  (file-notify-add-watch "/tmp" '(change attribute-change) 'myhandler)
  (trace-function 'file-notify-handle-event)
  (trace-function 'myhandler))

# echo xxx > /tmp/xxx

======================================================================
1 -> (file-notify-handle-event (file-notify (1 (create) "xxx" 0) 
file-notify-callback))
| 2 -> (myhandler ((1) created "/tmp/xxx"))
| 2 <- myhandler: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (1 (modify) "xxx" 0) 
file-notify-callback))
| 2 -> (myhandler ((1) changed "/tmp/xxx"))
| 2 <- myhandler: nil
1 <- file-notify-handle-event: nil

# chmod 777 /tmp/xxx

======================================================================
1 -> (file-notify-handle-event (file-notify (1 (attrib) "xxx" 0) 
file-notify-callback))
| 2 -> (myhandler ((1) attribute-changed "/tmp/xxx"))
| 2 <- myhandler: nil
1 <- file-notify-handle-event: nil

# touch /tmp/xxx

======================================================================
1 -> (file-notify-handle-event (file-notify (1 (attrib) "xxx" 0) 
file-notify-callback))
| 2 -> (myhandler ((1) attribute-changed "/tmp/xxx"))
| 2 <- myhandler: nil
1 <- file-notify-handle-event: nil
--8<---------------cut here---------------end--------------->8---

> And a question: Will the events read by `file-notify--wait-for-events'
> still be processed by the handler function?

Yes, they should.

> And what's the intention of (file-notify--wait-for-events 5
> file-notify--test-results)?  The timeout of 5 is reasonable, but the
> UNTIL argument here just defines that it waits until the very first of
> possibly up to nine yet missing events is awaited here, or do I get
> something wrong?

Well, this is an open point here. When waiting for events, you don't
know how many events will arrive for a given file operation. See the
first command above, "echo", it is good for 2 events.

So I've taken this heuristics, that after arrival of the first event the
other ones will arrive soon. I simply don't know better ...

gfilenotify could profit from the changes-done-hint event, which is
exactly this kind of information. But we don't have a similar mechanism
for inotify or w32notify, as far as I'm aware.

If you know of a better check for "alle events we wait for have arrived"
- go on.

> Bye,
> Tassilo

Best regards, Michael.