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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org,  21435@debbugs.gnu.org
> Date: Thu, 10 Sep 2015 19:37:26 +0200
> 
> > However, if all we want is to make sure the destination directory gets
> > a notification (so it could auto-revert), then this already happens on
> > MS-Windows (see the 'created' event above), and therefore nothing
> > should be done on Windows to support the user request above.
> 
> It's not only the destination directory, it's also the source directory
> which matters. Remember the initial use case, two dired buffers under
> `auto-revert-mode' control. The moved file must appear in the
> destination dired buffer, and it must disappear in the source dired buffer.

Yes, and both events happen in this scenario, on Windows as well as on
GNU/Linux.  So the fact that the move is not reported as a move will
not cause any problems in this use case.

> > Therefore, I submit that a better solution would be to make inotify
> > emulate what w32notify does, i.e. produce a synthetic 'added' event in
> > the destination directory when we get a 'moved-to' event that
> > specifies a destination directory different from the source.
> 
> Not necessary I believe. Due to inotify cookie mechanism, it will work
> robustly. And don't forget gfilenotify, which sends a `rename' event
> already on low-level.

I'm guessing that gfilenotify only does that when its back-end is
inotify.  E.g., I doubt that it could do this when it uses its
fallback polling method.

> >  . I'm not sure this kind of non-trivial logic is something that
> >    belongs to filenotify.el; it could well have a better place in
> >    auto-revert.el instead, as that is the level where the logic is
> >    needed and understood, or even in the Dired-specific function that
> >    auto-reverts a directory
> 
> If we only deliver `removed' and `created' events, none of those
> libraries would have a chance to pair them to a rename action.

They shouldn't rely on that in the first place, since this is
unreliable, as we just saw.

And in the case in point, it's unnecessary anyway, since all you need
is to have events in both source and destination.  These events do not
have to be 'rename' events.

> Essential information, like inotify cookies, will be lost.

On filenotify.el level, yes.  I thought filenotify.el exists to try to
present a more or less unified interface independent of the back-end.
If such differences in back-end behavior are seen by clients of
filenotify.el, then how is it different from invoking the back-end
directly?

> And yes, this information will be needed. Recently, I saw a discussion
> on sx, whether Emacs' `auto.revert-mode' could also support file
> renaming. That is, when a buffer is associated by a file, and that file
> is renamed outside Emacs, Emacs shall rename `buffer-name' and
> `buffer-file-name', and then revert. Nice idea ...

The problem we are discussing does not exist in this scenario, AFAIU.