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

Previous Next

Full log

Message #8 received at 21435 <at> debbugs.gnu.org (full text, mbox):

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

> From: Tassilo Horn <tsdh <at> gnu.org>
> Date: Tue, 08 Sep 2015 10:47:00 +0200
> 
> file-notify using the inotify backend reports wrong events after
> directory renames.  For example, with
> 
> (let* ((flags '(change attribute-change))
>        (handler (lambda (event)
> 		  (message "WATCH: %S" event)))
>        (x "/tmp/x")
>        (y "/tmp/x/y"))
>   (make-directory x)
>   (make-directory y)
>   (file-notify-add-watch x flags handler)
>   (file-notify-add-watch y flags handler))
> 
> the following events are reported after these shell operations:
> 
>   1. $ touch /tmp/x/y/test1
>      WATCH: ((12) created "/tmp/x/y/test1")
>      WATCH: ((12) attribute-changed "/tmp/x/y/test1")
>   2. $ mv /tmp/x/y /tmp/x/z
>      WATCH: ((11) renamed "/tmp/x/y" "/tmp/x/z") [2 times]
>   3. $ touch /tmp/x/z/test2
>      WATCH: ((12) created "/tmp/x/y/test2")
>      WATCH: ((12) attribute-changed "/tmp/x/y/test2")
> 
> In 3, the file created is actually /tmp/x/z/test2, not /tmp/x/y/test2.

With w32notify, I see something very similar:

  1. $ touch /tmp/x/y/test1
     WATCH: (133902432 created "d:/tmp/x/y/test1")
     WATCH: (133902432 changed "d:/tmp/x/y/test1")
     WATCH: (159542912 changed "d:/tmp/x/y")
  2. $ mv /tmp/x/y /tmp/x/z
     WATCH: (159542912 renamed "d:/tmp/x/y" "d:/tmp/x/z")

(Here the watching thread exist with abnormal status.)

  3. $ touch /tmp/x/z/test2
     WATCH: (133902432 created "d:/tmp/x/y/test2")
     WATCH: (133902432 changed "d:/tmp/x/y/test2")
     WATCH: (159542912 changed "d:/tmp/x/z")

> There is also a problem with single-file watches:
> 
> (let* ((flags '(change attribute-change))
>        (handler (lambda (event)
> 		  (message "WATCH: %S" event)))
>        (x "/tmp/x"))
>   (with-temp-buffer
>     (insert "TEST\n")
>     (write-file x))
>   (file-notify-add-watch x flags handler))
> 
>   1. $ mv /tmp/x /tmp/y
>      WATCH: ((1 . "x") renamed "/tmp/x" "/tmp/y") [2 times]
>   2. $ echo "more" >> /tmp/y
>      ;; no notification
>   3. $ touch /tmp/x
>      WATCH: ((1 . "x") created "/tmp/x")
>      WATCH: ((1 . "x") changed "/tmp/x")

On Windows:

  1. $ mv /tmp/x /tmp/y
     WATCH: (159487136 renamed "d:/tmp/x" "d:/tmp/x")
  2. $ echo "more" >> /tmp/y
     ;; no notification
  3. $ touch /tmp/x
     WATCH: (159487136 created "d:/tmp/x")
     WATCH: (159487136 changed "d:/tmp/x")

> So in the case of single-file watches, the watch seems to stick to a
> filename rather than a file.  Well, I think that's ok but then I would
> expect it to be similar with directories, e.g., in the first example
> step 3 should not report a notification because I intended to watch
> /tmp/x/y and not /tmp/x/z.

I don't see any problems here.  filenotify.el just reports to us what
the notification back-end receives.  It doesn't (and shouldn't, IMO)
include any non-trivial logic to "fix" the back-ends in these tricky
cases, because it has no idea what the application will want to do
with that.  Its role is to present a platform-independent API that
uses one of the available back-ends, that's all.

IOW, technically, the file/directory you watched disappeared from the
filesystem, so what is reported afterwards is IMO entirely resonable
at this low level.

One application we have on top of filenotify.el is auto-revert.el.
Now, if you see some user-level problems there when files are
renamed/deleted, please report them.

> Another thing is that renames always seem to be reported twice (although
> the example in the manual lists only one event but that example has
> probably gathered with the gfilenotify backend).

This doesn't happen with w32notify.  filenotify.el includes some code
to produce a single notification out of the 2 reported by back-ends in
this case; perhaps something doesn't work there with inotify.  Can you
step through the code and see why?

Previous Next

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