From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.bugs Subject: bug#26126: 26.0.50; file-notify-rm-watch removes arbitrary watches Date: Sat, 25 Mar 2017 09:57:52 +0100 Message-ID: <87a889hgxb.fsf@luca> References: <87r31x9ulw.fsf@luca> <87shmcney8.fsf@detlef> <87efxw7xvc.fsf@luca> <87mvcjophx.fsf@detlef> <87tw6rssoi.fsf@luca> <87pohfkmvh.fsf@detlef> <87lgs2sobr.fsf@luca> <87y3w2gywc.fsf@detlef> <8737e8excq.fsf@luca> <877f3el80j.fsf@luca> <83zig9c186.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490432357 30451 195.159.176.226 (25 Mar 2017 08:59:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Mar 2017 08:59:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 26126@debbugs.gnu.org, michael.albinus@gmx.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 25 09:59:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crhXN-0006lu-8R for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Mar 2017 09:59:05 +0100 Original-Received: from localhost ([::1]:36420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crhXT-0007wr-9k for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Mar 2017 04:59:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crhXN-0007wl-RG for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2017 04:59:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1crhXK-0002mi-Nj for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2017 04:59:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45032) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1crhXK-0002mc-Jo for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2017 04:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1crhXK-00013S-9o for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2017 04:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas Politz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Mar 2017 08:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26126 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26126-submit@debbugs.gnu.org id=B26126.14904322943997 (code B ref 26126); Sat, 25 Mar 2017 08:59:02 +0000 Original-Received: (at 26126) by debbugs.gnu.org; 25 Mar 2017 08:58:14 +0000 Original-Received: from localhost ([127.0.0.1]:43231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crhWY-00012P-Im for submit@debbugs.gnu.org; Sat, 25 Mar 2017 04:58:14 -0400 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:52843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crhWW-000128-BG for 26126@debbugs.gnu.org; Sat, 25 Mar 2017 04:58:12 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Original-Received: from localhost (ip5f5bdecf.dynamic.kabel-deutschland.de [95.91.222.207]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id F120C179B3B4; Sat, 25 Mar 2017 09:57:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1490432273; bh=EFx5O+tEk635Uo3w3VnFcLOYz1w=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=DT5rCSshBnEqeKdEaW0Jj4kxzLO7bzdUAuX5gRqlC7Q/+/aD/VEuqVYaSg0odIw2z uH3Ahl8G1tFfbraVV7H4q7bgV/CkhYRswW2w004tPxRLBJtTrMReWPnWfkmcqwGP0v WYXNm/LWRkf8Juo9HRfGjyvb4Rp5FlpKh7DPaKhE= In-Reply-To: <83zig9c186.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Mar 2017 09:35:53 +0300") 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" Xref: news.gmane.org gmane.emacs.bugs:130917 Archived-At: Eli Zaretskii writes: > Thanks, but I have difficulty reading it. Could you please provide a > short legend? Sorry, I forgot to do that. The first column is the name of the test. The 2nd lists all watched entities mapped to symbolic names. Further columns list the events for specific back ends, which may refer to the same names. Because kqueue does not support watching nonexistent files, in most cases I did create them before starting to watch. That's why there are usually no creation events. In every test, I deleted all participating files as the last step. A `(timeout n)' event means just that: We waited for n seconds without receiving a stopped event. If the event lists a name anon-xyz, it means that it contained the filename of a non-watched file. This may signify a bug. All test ran with the last patched I've posted applied. >> Finally, I'm tempted to suggest to get rid of the flags argument of >> file-notify-add-watch. > The flags are there for the operations where the differences matter. When does it matter ? The callback can just ignore the events its not interested in. The sole advantage would be reduced complexity, but, of course, it shouldn't be done, if this is not seen as a sufficient reason. Also: I think in the end we want to add a layer above filenotify.el, with the added ability of multiplexing events in a directory to multiple watches, watching files in that directory. The current implementation (including the patch) returns a new descriptor for every watch. This is good for a low-level api, because it is easy to manage. The downside is, that it does not scale very well. For example every tramp watch starts a new process and (it seems to me) every w32 watch a new thread. And, coming back to the original point, in this case we usually need to watch with all flags enabled anyway. -ap