bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted

[Tassilo Horn]

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