From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#22534: File notify broken on Windows Date: Thu, 4 Feb 2016 10:49:42 +0100 Message-ID: References: <83h9hrytom.fsf@gnu.org> <87lh72xln0.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113cf21e8d3a2b052aeea8f0 X-Trace: ger.gmane.org 1454579479 3682 80.91.229.3 (4 Feb 2016 09:51:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 09:51:19 +0000 (UTC) Cc: 22534@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 04 10:51:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aRGZC-0001nV-7I for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 10:51:10 +0100 Original-Received: from localhost ([::1]:40581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRGZB-0006To-Mv for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 04:51:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRGZ7-0006TU-Io for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 04:51:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRGZ4-00087h-Bl for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 04:51:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRGZ4-00087X-7V for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 04:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRGZ4-0007Ik-0G for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 04:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Feb 2016 09:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22534 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22534-submit@debbugs.gnu.org id=B22534.145457940928006 (code B ref 22534); Thu, 04 Feb 2016 09:51:01 +0000 Original-Received: (at 22534) by debbugs.gnu.org; 4 Feb 2016 09:50:09 +0000 Original-Received: from localhost ([127.0.0.1]:58933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRGYC-0007He-Nb for submit@debbugs.gnu.org; Thu, 04 Feb 2016 04:50:09 -0500 Original-Received: from mail-oi0-f45.google.com ([209.85.218.45]:33560) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRGYB-0007HR-Px for 22534@debbugs.gnu.org; Thu, 04 Feb 2016 04:50:08 -0500 Original-Received: by mail-oi0-f45.google.com with SMTP id j125so12088977oih.0 for <22534@debbugs.gnu.org>; Thu, 04 Feb 2016 01:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fVqumR/EA9/X/Z0UmmvanUhHMvrAKhbP0BWRmB6WHq4=; b=ZK10FjDWKtzKHqdqwoprQGfpWiwdVpkwI0JdEE6bqQPt6MRNze0HRPTqhLyBBWIXVA OzSCkHfRt1zc8H8aRylzRzx4GGiSibcDY8bvI/dT947xyG9RfqMNQl7jmAJ6p4BleLZ0 tK32j4Fs9cGNLOLQGqIek79sr7JMvH1MT2hbI8P23ywuYKp0mTe1IZjDvYx5FMeAIQT5 v8FoiJSLDG3XXGcB9L5ZMC+QMwX/FLTrANUwOvPHbA/XjDyvkq7AmY6sJyIJKa6VttyD ZTZXe2ifF/BugMIV67I4tEJAmq7RUrK/p7a5rSjnJ6wsKJXTzvWoo3odWlACuT9lv4uL 8HpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fVqumR/EA9/X/Z0UmmvanUhHMvrAKhbP0BWRmB6WHq4=; b=QX0jp5SIh9QD4gfZOAHgzdDJBYnhv13s/11rX9KfbOFvEMWz7unny2xx4bZoLuS5A0 bUDOIxduiTNP0AbddZV/axAZ+OMXQCWS38/VUC9c5XRJOVPlWER5ZI5aUMfZl+uk7/PV 6kowyYH4Fk7KCJbIZ1e77/G1FEvJU6MS9hYby+dsQtE6Bqkrf2vDZKr7k4S5DlIYEHil 9Rc3xIsS3viobGdBDQSwOYwxL7Fyia8l/CxMaDcKi9opajhaXoLfWmoEr8sh9brhg1jN eFLkX3zaqo4E8mKsn/Cc5vQ37t21KwOvK7DiwjqlgBNQD2sggNUNrX0Za/3ib54dbdM/ tFdA== X-Gm-Message-State: AG10YOQJB7N8S47oVu5Q6XMCNg2pUW9d19ZyIBFButJzV4HIhVmyXgTn3xXdRB4SxbVki4xeqQkmUzd3WzbPZw== X-Received: by 10.202.50.139 with SMTP id y133mr2700403oiy.19.1454579401962; Thu, 04 Feb 2016 01:50:01 -0800 (PST) Original-Received: by 10.202.78.67 with HTTP; Thu, 4 Feb 2016 01:49:42 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112401 Archived-At: --001a113cf21e8d3a2b052aeea8f0 Content-Type: text/plain; charset=UTF-8 A couple of my findings : - notifications returned are not the same whether you run the tests in batch mode or interactive mode. In interactive mode, there is a deleted notification which is sent when your remove the directory being watched. This event is not seen when running in batch mode (make check). I wonder what could make a difference. - in the test file-notify-test06-many-events to check that events are not dropped : I have to lower the 1000 number. The test fails as soon as I go higher than around 260. Is there some limit here ? Once the limit is reached, only the first notification is returned. - there is this small patch that needs to be applied : diff --git a/test/automated/file-notify-tests.el b/test/automated/file-notify-tests.el index de64f50..51a898e 100644 --- a/test/automated/file-notify-tests.el +++ b/test/automated/file-notify-tests.el @@ -507,7 +509,7 @@ file-notify--test-with-events ;; w32notify does not distinguish between `changed' and ;; `attribute-changed'. ((string-equal (file-notify--test-library) "w32notify") - '(changed changed changed changed)) + '(changed changed)) ;; For kqueue and in the remote case, `write-region' ;; raises also an `attribute-changed' event. ((or (string-equal (file-notify--test-library) "kqueue") Overall, I don't think anymore that the patch by Michael has broken w32 file notifications but rather that the new tests have highlighted some potential problems with it. Regards, Fabrice 2016-02-03 13:15 GMT+01:00 Fabrice Popineau : > > > 2016-02-03 9:07 GMT+01:00 Michael Albinus : > >> Fabrice Popineau writes: >> >> > You will find the commit below (with not too much surprise). >> > However, I don't have much time these days to sort this out. >> >> I'll check next days, need to find an MS Windows machine first. >> >> > Thanks Michael. > > I have observed something weird during the file-notify tests. > I traced file-notify-test02-events. > The read_event function doesn't time out in 0.1s as it is supposed to. > It waits for the time specified by (file-notify--test-timeout) before > returning the right value. (Well actually, the value returned by the third > test > in file-notify-test02-events is wrong but it is another story). > > So I'm afraid some logic is wrong, and possibly not only in file-notify > but also in the way w32 should handle those timeouts. > > Fabrice > > --001a113cf21e8d3a2b052aeea8f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A couple of my findings :

- notificatio= ns returned are not the same whether you run the tests in batch mode or int= eractive mode.
=C2=A0 In interactive mode, there is a deleted not= ification which is sent when your remove the directory being watched.
=
=C2=A0 This event is not seen when running in batch mode (make check).= I wonder what could make a difference.
- in the test file-notify= -test06-many-events to check that events are not dropped : I have to lower = the 1000 number.
=C2=A0 The test fails as soon as I go higher tha= n around 260. Is there some limit here ? Once the limit is reached, only=C2= =A0
=C2=A0 the first notification is returned.
- there = is this small patch that needs to be applied :

diff --git a/test/automated/file-notify-tests.el b/test/automated/file-no= tify-tests.el
index de64f50..51a898e 100644
--- a/test/= automated/file-notify-tests.el
+++ b/test/automated/file-notify-t= ests.el
@@ -507,7 +509,7 @@ file-notify--test-with-events
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; w32notify = does not distinguish between `changed' and
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; `attribute-changed'.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((string-equal (fil= e-notify--test-library) "w32notify")
- =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 '(changed changed changed changed))<= /div>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 '(changed = changed))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ;; For kqueue and in the remote case, `write-region'
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; raises also an `attribut= e-changed' event.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0((or (string-equal (file-notify--test-library) "kqueue&qu= ot;)

Overall, I don't think anymore that= the patch by Michael has broken w32 file notifications
but rathe= r that the new tests have highlighted some potential problems with it.

Regards,

Fabrice

201= 6-02-03 13:15 GMT+01:00 Fabrice Popineau <fabrice.popineau@gmail.= com>:

=

= 2016-02-03 9:07 GMT+01:00 Michael Albinus <michael.albinus@gmx.de= >:
Fabrice Popineau <fabrice.popineau@gmail.com= > writes:

> You will find the commit below (with not too much surprise).
> However, I don't have much time these days to sort this out.

I'll check next days, need to find an MS Windows machine first.<= br>

Thanks Michael.

<= /div>
I have observed something weird during the file-notify tests.
I traced file-notify-test02-events.
The read_event functio= n doesn't time out in 0.1s as it is supposed to.
It waits for= the time specified =C2=A0by (file-notify--test-timeout) before
r= eturning the right value. (Well actually, the value returned by the third t= est
in file-notify-test02-events is wrong but it is another story= ).

So I'm afraid some logic is wrong, and poss= ibly not only in file-notify
but also in the way w32 should handl= e those timeouts.
=
Fabrice


--001a113cf21e8d3a2b052aeea8f0--