From: Tassilo Horn <tsdh@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 21432@debbugs.gnu.org
Subject: bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
Date: Tue, 08 Sep 2015 10:11:59 +0200 [thread overview]
Message-ID: <8737yp5nzk.fsf@gnu.org> (raw)
In-Reply-To: <87wpw1uzd0.fsf@gmx.de> (Michael Albinus's message of "Tue, 08 Sep 2015 09:47:07 +0200")
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,
>> I don't have a strong opinion about what the right behavior would be
>> but at least it seems inconsistent that you get the error only with
>> deleted directories. I guess the best solution was if
>> `file-notify-rm-watch' never signaled an error (then the docs can
>> stay as they are), and there would be some `file-notify-valid-p'
>> predicate which would test if a given descriptor still denotes a
>> valid file or directory. I guess the latter has probably some
>> function equivalent in the respective backend APIs, and even if not,
>> it can be implemented by inspecting `file-notify-descriptors'.
>
> `file-notify-rm-watch' is just a cleanup function, it's not worth to
> add some error handling. I will wrap the call of the native handlers
> by catching `file-notify-error'. Alternatively, `inotify-rm-watch'
> could be adapted not to raise an error in this case.
Great, thanks.
> `file-notify-valid-p' is a nice idea; I will see how I could add it.
> At least for the w32 case I would need some help from Eli, in order to
> see whether the native library supports such a check.
I just wanted to write that such a predicate would not strictly be
needed because if one really cares, she could determine when a
descriptor becomes invalid by handling all delete notifications. But
that's not really true because when watching a directory, you only
receive events for the contents of the directory, not for the directory
itself. That is, if you want to receive notifications about changes to
your watched directory itself, then you need to watch also its parent
directory.
Bye,
Tassilo
next prev parent reply other threads:[~2015-09-08 8:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 6:36 bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Tassilo Horn
2015-09-08 7:47 ` Michael Albinus
2015-09-08 8:11 ` Tassilo Horn [this message]
2015-09-08 15:51 ` Eli Zaretskii
2015-09-08 15:49 ` Eli Zaretskii
2015-09-08 16:01 ` Michael Albinus
2015-09-12 10:18 ` Michael Albinus
2015-09-12 15:11 ` Eli Zaretskii
2015-09-12 18:09 ` Michael Albinus
2015-09-13 19:23 ` Michael Albinus
2015-09-14 6:08 ` Tassilo Horn
2015-09-14 7:08 ` Eli Zaretskii
2015-09-14 7:40 ` Tassilo Horn
2015-09-14 7:56 ` Tassilo Horn
2015-09-14 13:22 ` Eli Zaretskii
2015-09-14 20:23 ` Michael Albinus
2015-09-15 7:38 ` Eli Zaretskii
2015-09-15 8:00 ` Michael Albinus
2015-09-15 8:22 ` Eli Zaretskii
2015-09-15 11:54 ` Michael Albinus
2015-09-15 12:51 ` Eli Zaretskii
2015-09-15 12:56 ` Michael Albinus
2015-09-16 14:45 ` Michael Albinus
2015-09-16 17:08 ` Eli Zaretskii
2015-09-16 17:26 ` Michael Albinus
2015-09-16 17:55 ` Eli Zaretskii
2015-09-16 18:28 ` Michael Albinus
2015-09-15 5:53 ` Tassilo Horn
2015-09-14 7:35 ` Eli Zaretskii
2015-09-14 7:37 ` Michael Albinus
2015-09-15 13:02 ` Michael Albinus
2015-09-15 13:56 ` Eli Zaretskii
2015-09-16 13:54 ` Michael Albinus
2015-09-20 17:23 ` Michael Albinus
2015-09-20 19:19 ` Eli Zaretskii
2015-09-21 13:40 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8737yp5nzk.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=21432@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).