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, 18 Mar 2017 21:37:45 +0100 Message-ID: <878to21fty.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1489869559 19648 195.159.176.226 (18 Mar 2017 20:39:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Mar 2017 20:39:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 26126@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 18 21:39:13 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 1cpL7x-0003r3-Qs for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Mar 2017 21:39:06 +0100 Original-Received: from localhost ([::1]:54625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cpL83-0001hh-Ja for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Mar 2017 16:39:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cpL7y-0001gM-8u for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2017 16:39:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cpL7v-0004bV-4E for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2017 16:39:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36166) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cpL7u-0004bR-QP for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2017 16:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cpL7u-0000zg-Ey for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2017 16:39: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, 18 Mar 2017 20:39: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.14898694883751 (code B ref 26126); Sat, 18 Mar 2017 20:39:02 +0000 Original-Received: (at 26126) by debbugs.gnu.org; 18 Mar 2017 20:38:08 +0000 Original-Received: from localhost ([127.0.0.1]:34365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cpL72-0000yQ-E7 for submit@debbugs.gnu.org; Sat, 18 Mar 2017 16:38:08 -0400 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:40971) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cpL70-0000xt-5f for 26126@debbugs.gnu.org; Sat, 18 Mar 2017 16:38:06 -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 658B6179B32F; Sat, 18 Mar 2017 21:37:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1489869466; bh=cQEWIbjJt6y8PB4dTsR59YLfiAQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=jfN1AYiJL9Ex7/ZRCHTn6uSMwShkO3fPtO4XqcpZaKQ5jZZqV1oq/Jr64Q5aSlSd1 xZdboVyHxQFFb+vC2DzngO2x8X3wSTwz1e0QjnITCx+f4faa9fGFHu1Ly3O8tLLoQV ICMo7ntDUzWUzHhvqKmutagy2ycn/fuWx9w2O28c= In-Reply-To: <87y3w2gywc.fsf@detlef> (Michael Albinus's message of "Sat, 18 Mar 2017 20:36:51 +0100") 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:130718 Archived-At: Michael Albinus writes: > Andreas Politz writes: >> + A watched hard-link for some other file may not receive its events, >> due to string-equal being used for file-comparisons. Shouldn't >> file-equal be used instead ? > > How does inotify (and the other libraries) work in this case? Does it > support hard links? We should not add more logic than the native > libraries offer. inotify seems to be inode-based, so it emits notifications independent of the filename used. I think that hard-links are not commonly used under win32, but I don't know. I we stay with string-equal, we are watching filenames, not files. Which is probably sufficient/OK. Maybe this should be mentioned in the manual, I made a note of it. > >> + Watching a /dir/file may receive events (e.g. touch /dir) for dir. > > Could you pls give an example? With inotify: (let ((desc (file-notify-add-watch "/tmp/file" '(attribute-change) (lambda (_) (cl-assert nil))))) (unwind-protect (progn (shell-command "touch /tmp") (sit-for 3)) (file-notify-rm-watch desc))) >> + Why the seemingly arbitrary exclusion of backup-files in >> file-notify-callback ? What if someone wants to track the creation of >> said files ? > > When a file under supervision is renamed during backup, the supervision > might be stopped. This case must be handled. Yes, I see. >> + Why is the existence of kqueue checked for the handler in >> file-notify-add-watch ? After all we don't know how this handler will >> operate. > > Why don't we know what kqueue does? This: (if handler ;; A file name handler could exist even if there is no local ;; file notification support. (setq desc (funcall handler 'file-notify-add-watch ;; kqueue does not report file changes in ;; directory monitor. So we must watch the file ;; itself. (if (eq file-notify--library 'kqueue) file dir) flags callback)) Why should we assume that handler is somehow related to kqueue ? I think its just a copy and paste error. The comment should be moved to the actual library call below this. I also wonder, if the passed argument should not always be the filename for which the watch was requested, as opposed to its directory. After all we should not make assumptions about the abilities of the underlying mechanism. For example it could work similar to kqueue, i.e. with an inability to watch directories. Thanks for you response, -ap