Re: [PATCH] Added basic file system watching support.

[Stefan Monnier]

> I don't think the patch will be ready for 24.3.  It is still not complete and
> needs some heavy testing.

I'm not very familiar with inotify and other file-system watching
facilities, so just as a guideline for others's reviews: I'm OK with
installing in 24.3 a non-complete version of the code, and I'm OK to
install before the freeze a code that needs more testing, *but* only if
those missing functionalities and testing won't require a redesign of
the API.

>> It seems that each event is either of form (SYMBOL . FILENAME) where
>> FILENAME is the watched object, or of the form (SYMBOL from NAME . COOKIE)
>> where NAME is the file added/removed from the watched object (a
>> directory, presumably), but this object's FILENAME is not present.
>> Any particular reason for this inconsistency?

> FILENAME is not always the watched object.  If a directory is watched then
> it is the file name of the file inside the directory.  This should really not
> be used as identification for the watched object!  That's why CALLBACK
> also gets the ID.

I understand that NAME refers to the added/removed file, but I'm
wondering why we don't also add FILENAME (the name of the directory) to
the event.  If inotify doesn't provide it, we can provide it
ourselves, right?
Or is it rarely/never needed?
Or is it because that directory may change name without us knowing?

>> I guess that several `ev' objects can have the same `ev->cookie'
>> value, right?
> Yes exactly.  The value is unimportant as long as it is unique to an event
> and can be compared with eq.  What would you propose as an alternative
> object here?

I can't remember enough of the context, but objects that are "unique"
are plentiful.  A cons cell would do, regardless of its value, for
example (now, as to whether it's better than a number, that depends on
what it's use for, e.g. whether you can put the cons's fields to good
use).

> The problem is that even after removal of a watch descriptor there can
> still be issues in the queue.  Therefore I think it is best to ignore any
> events for files we do not watch.  There could also be event types we do not
> know about when inotify gets expanded.  That's why I think unknown
> event types should be ignored instead of reporting an error.

Sounds fair.  Please mention it in the comments.


        Stefan