GNU bug report logs - #21435
25.0.50; file-notify has problems after renames

Previous Next

Full log

View this message in rfc822 format

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21435 <at> debbugs.gnu.org
Subject: bug#21435: 25.0.50; file-notify has problems after renames
Date: Tue, 08 Sep 2015 21:47:50 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I stepped through inotify_callback in inotify.c which can read 64
>> byte from inotifyfd where the size of one inotify event is 32 and
>> that produces 2 emacs events (although I cannot see which events are
>> created).  The Locals GUD frame always shows just nil for the `event'
>> local variable even after the assignments to it and I stepped into
>> the then-branch of an `if (!NILP(event.arg))' which makes it pretty
>> clear that it cannot be nil.  Why is that?
>
> Could be some gud bug.  Do you see the same when you invoke GDB from
> the shell?

Oh, my GDB foo on the command line ends with making backtraces. ;-)

But just typing in "info locals" in the *gud-bootstrap-emacs* buffer is
about the same, no?  And that shows

  event = {kind = FILE_NOTIFY_EVENT, part = scroll_bar_nowhere, code = 0, modifiers = 0, x = 0, y = 0, timestamp = 0, frame_or_window = 0, arg = 0}

whereas the relevant line in the locals GUD window is just

  struct input_event event        nil

So that looks like a bug.  I guess I should report this, or will you fix
this right now?

>> Is that expected that when edebugging event handlers one might miss
>> events?
>
> I always use 'message' when debugging event-driven code.  I just don't
> trust edebug enough in these cases.

Ok.

>> Anyway, eventually I found and fixed the culprit which simply was
>> that the watch descriptors of the pending and the current event were
>> compared with `eq' which is not valid because inotify descriptors are
>> conses.  I've changed the comparison to `equal' which fixes the
>> double-reporting issue.
>
> Thanks.  But meanwhile Michale explained that this behavior was on
> purpose, due to a recent change.  Do you see 2 events only when a file
> was moved to a different directory, or also when it is renamed in the
> same directory?

When renaming in the same directory.  I think Michaels case is where you
move a file from watched directory A to watched directory B, and then
you want the rename event reported to both handlers.  The case I fixed
is just that both source and target watch descriptor are actually the
same but not identical Lisp objects.

Bye,
Tassilo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.