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

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org,  21435@debbugs.gnu.org
> Date: Thu, 10 Sep 2015 20:20:54 +0200
> 
> >> >  . 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.
> 
> Nope. When filenotify.el sends a `renamed' event, it must be
> reliable.

That's not what I meant.  What I meant was that applications cannot
rely on getting a 'renamed' event when files are moved between
directories, they should be prepared to deal with 'deleted' and
'created' anyway.

> > 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.
> 
> In the use cases we know today, you are right. But there might be other
> use cases where it matters. And again, `renamed' events provide more
> information than single `deleted' and `created' events.

Those use cases will have to handle 'deleted' and 'created', if they
want to work on all supported platforms.  By sending sometimes
'renamed' and sometimes 'deleted' followed by 'created', we ask the
users to do more work, and gratuitously expose them to platform
differences that filenotify.el was supposed to conceal.

> >> 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?
> 
> There is already a difference: native gfilenotify gives us a `rename'
> event. Shall we convert it to `deleted' and `created'?

Yes.

> This would reduce the information.

Applications that don't want to lose that information can always call
back-ends directly.  By using filenotify.el, they agree to losing some
information, and in return gain uniformity and less coding.

> >> 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.
> 
> That scenario would work only if there is a `renamed' event. How else
> autorevert could decide, that a file has been moved? What is its new name?

In the same directory, there _is_ a 'renamed' event.  We are
discussing a situation when a file was moved to another directory,
which is not what this scenario is about.