From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Added basic file system watching support. Date: Fri, 28 Sep 2012 10:13:52 -0400 Message-ID: References: <6218185.ViukoKRdFp@descartes> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348841653 6422 80.91.229.3 (28 Sep 2012 14:14:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 14:14:13 +0000 (UTC) Cc: Leo , emacs-devel@gnu.org To: =?iso-8859-1?Q?R=FCdiger?= Sonderfeld Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 28 16:14:17 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1THbKa-0000eR-HZ for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 16:14:16 +0200 Original-Received: from localhost ([::1]:43691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THbKV-0003Hc-2s for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 10:14:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THbKN-0003HD-Gm for emacs-devel@gnu.org; Fri, 28 Sep 2012 10:14:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THbKF-000189-Hh for emacs-devel@gnu.org; Fri, 28 Sep 2012 10:14:03 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:36422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THbKF-000185-DY for emacs-devel@gnu.org; Fri, 28 Sep 2012 10:13:55 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q8SEDqt3023974; Fri, 28 Sep 2012 10:13:53 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id AFBABB404D; Fri, 28 Sep 2012 10:13:52 -0400 (EDT) In-Reply-To: <6218185.ViukoKRdFp@descartes> (=?iso-8859-1?Q?=22R=FCdiger?= Sonderfeld"'s message of "Fri, 28 Sep 2012 15:06:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153678 Archived-At: > 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