From: Eli Zaretskii <eliz@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 21435@debbugs.gnu.org, tsdh@gnu.org
Subject: bug#21435: 25.0.50; file-notify has problems after renames
Date: Thu, 10 Sep 2015 18:45:13 +0300 [thread overview]
Message-ID: <837fny5ldi.fsf@gnu.org> (raw)
In-Reply-To: <87si6mttsf.fsf@gmx.de>
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org, 21435@debbugs.gnu.org
> Date: Thu, 10 Sep 2015 13:09:36 +0200
>
> file-notify-handle-event' is called directly by the low-level library,
> w32notify here. It sends the events
>
> (file-notify (100286608 removed "xxx"))
> (file-notify (100286608 added "xxx"))
> (file-notify (100286560 removed "xxx"))
Yes.
> The first two events are raised by the file name handler for d:/usr/eli/data.
> Maybe "xxx" did exist already in that directory?
No, it didn't. I don't know why w32 sends this strange notification,
but the fact is it does. (That doesn't happen when moving a
directory, btw, only when moving files.)
> The last event comes from from file name handler for d:/tmp - this looks
> OK. Well, the order of the events is not as expected (the third event
> shall be the first one), but we never gave a promise for a canonical order.
>
> I would say, that w32notify does not send the renamed-from and
> renamed-to events, as expected. Maybe they are sent only in case of
> renaming a file in the same directory?
Yes, that's exactly what happens. Which IMO is entirely reasonable,
since each watch watches only a single directory. That inotify has
some kind of "global" perspective on such rename events is a bonus,
but we cannot expect that.
This, of course, breaks the basic assumption of the design intended to
provide this feature:
> Two days ago (commit dbdc459a48091f5953faf14bcaaa7e6d37fbf024), I've
> changed filenotify.el to fire 2 events `renamed' in case the directories
> of the source and target are different. This was triggered by a user
> report, that he wants to have auto-revert-mode for two different
> directories under dired control. So the event is sent for the two
> different handlers activated by the respective *-add-watch calls.
The design expects 2 'move'/'renamed' events, but that's not
guaranteed, and doesn't happen on w32. If we want to conflate
'removed' followed by 'added' into a rename across directories, we
will need changes in filenotify.el, and will risk false positives,
because it could really be a deletion followed by a creation of a file
by the same name.
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.
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.
Finally, two more comments about this:
. I wish such changes were discussed, and the various alternatives
examined, before the code is changed
. 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
next prev parent reply other threads:[~2015-09-10 15:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 8:47 bug#21435: 25.0.50; file-notify has problems after renames Tassilo Horn
2015-09-08 16:03 ` Eli Zaretskii
2015-09-08 18:04 ` Michael Albinus
2015-09-08 18:21 ` Eli Zaretskii
2015-09-08 19:28 ` Tassilo Horn
2015-09-09 18:15 ` Michael Albinus
2015-09-09 19:01 ` Tassilo Horn
2015-09-09 20:23 ` Tassilo Horn
2015-09-10 11:23 ` Michael Albinus
2015-09-10 15:31 ` Tassilo Horn
2015-09-10 17:50 ` Michael Albinus
2015-09-10 19:22 ` Tassilo Horn
2015-09-11 9:53 ` Michael Albinus
2015-09-11 12:17 ` Tassilo Horn
2015-09-11 12:32 ` Eli Zaretskii
2015-09-12 8:44 ` Michael Albinus
2015-09-11 9:45 ` Michael Albinus
2015-09-11 12:11 ` Tassilo Horn
2015-09-09 18:41 ` Michael Albinus
2015-09-09 19:21 ` Eli Zaretskii
2015-09-10 11:09 ` Michael Albinus
2015-09-10 15:45 ` Eli Zaretskii [this message]
2015-09-10 17:37 ` Michael Albinus
2015-09-10 18:03 ` Eli Zaretskii
2015-09-10 18:20 ` Michael Albinus
2015-09-10 18:55 ` Eli Zaretskii
2015-09-11 12:51 ` Michael Albinus
2015-09-08 19:05 ` Tassilo Horn
2015-09-08 19:19 ` Eli Zaretskii
2015-09-08 19:47 ` Tassilo Horn
2015-09-09 2:39 ` Eli Zaretskii
2015-09-09 6:13 ` Tassilo Horn
2015-09-20 17:26 ` Michael Albinus
2015-09-20 19:36 ` Eli Zaretskii
2015-09-21 6:25 ` Michael Albinus
2015-09-21 7:54 ` Eli Zaretskii
2015-09-21 10:13 ` Michael Albinus
2015-09-21 10:14 ` Eli Zaretskii
2015-09-21 13:11 ` Michael Albinus
2015-09-21 13:31 ` Eli Zaretskii
2015-09-21 13:38 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837fny5ldi.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=21435@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
--cc=tsdh@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.