From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Johan Claesson Newsgroups: gmane.emacs.bugs Subject: bug#13860: 24.2; dir-locals-directory-cache unreliable in one rare case Date: Sun, 18 Aug 2019 21:19:01 +0200 Message-ID: <87y2zqs2my.fsf@bredband.net> References: <87lia4d9xh.fsf@bredband.net> <8736i3ymrf.fsf@mouse.gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="244100"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: 13860@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 18 21:20:22 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hzQiy-0011G2-4I for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Aug 2019 21:20:20 +0200 Original-Received: from localhost ([::1]:42632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzQix-0007k0-3N for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Aug 2019 15:20:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55092) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzQih-0007ie-Qz for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2019 15:20:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hzQig-00065q-KK for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2019 15:20:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49852) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hzQig-00065g-B2 for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2019 15:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hzQig-0000cF-5V for bug-gnu-emacs@gnu.org; Sun, 18 Aug 2019 15:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Johan Claesson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Aug 2019 19:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13860 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 13860-submit@debbugs.gnu.org id=B13860.15661559492291 (code B ref 13860); Sun, 18 Aug 2019 19:20:02 +0000 Original-Received: (at 13860) by debbugs.gnu.org; 18 Aug 2019 19:19:09 +0000 Original-Received: from localhost ([127.0.0.1]:58673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hzQho-0000as-LF for submit@debbugs.gnu.org; Sun, 18 Aug 2019 15:19:08 -0400 Original-Received: from mail204c50.megamailservers.eu ([91.136.10.214]:56078 helo=mail193c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hzQhl-0000ai-B7 for 13860@debbugs.gnu.org; Sun, 18 Aug 2019 15:19:06 -0400 X-Authenticated-User: johanclaesson@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1566155943; bh=UUrLNxwfymrExbBBDDieTKA5jtkH6zwxWadHAinnRtE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NJT8PvB3d+YIRUz6ViOBo/E/mynxriCMlsjVSCnYbhxnrab/g2JH6KYGKEw5RaWW9 wiX6wTgBAu7cpzZ3Y25JPX3amUSSDReBESxYzfwu7drtF6LRgF4WA3FolZSLxLCJWV H+ACvl2YVbO2b9iTsCrMkoBytKPpZmYzE0+1lBN8= Feedback-ID: johanclaesson@b Original-Received: from goblin (c-969c72d5.04-99-73746f3.bbcust.telenor.se [213.114.156.150]) (authenticated bits=0) by mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7IJJ1VL013322; Sun, 18 Aug 2019 19:19:03 +0000 In-Reply-To: <8736i3ymrf.fsf@mouse.gnus.org> (Lars Ingebrigtsen's message of "Wed, 14 Aug 2019 23:18:44 -0700") X-CTCH-RefID: str=0001.0A0B020C.5D59A4A7.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=Yv8hubQX c=1 sm=1 tr=0 a=es36QED1PvwHim/y0rXxVA==:117 a=es36QED1PvwHim/y0rXxVA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=DPSeMV08AAAA:8 a=lO1WgUTTi_PpNneSoh8A:9 a=bFKhLQa2sdSHufCki0ND:22 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: 209.51.188.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:165353 Archived-At: Hi Lars, I can reproduce with emacs -Q on Emacs 27 (ee1c638cff). I get the wrong value about 1 time in 3 tries. (I cannot reproduce without -Q. In particular when magit-autorevert is loaded that will "fix" the issue. Probably by slowing things down.) My original description is a bit incorrect/misleading. The race condition is not about if it occurs in the same second or not. But it is about when two file modification timestamps are equal. What happens seem to be that sometimes the second time the .dir-locals.el file is written (now with value foo = 2) the file will get the same timestamp as it already have from the first write. At this point the dir-locals-class-alist cache is not updated (it still have foo = 1). The cache is supposed to be updated when reading the .dir-locals.el. But that is only done if .dir-locals.el modification timestamp is newer than the timestamp in the cache. Sometimes they are the same just because the clock have not ticked forward. I think one way to remedy this would be to explicitly invalidate the directory cache every time a .dir-local.el file is modified. Something like the following seem to do the trick: diff --git a/lisp/files-x.el b/lisp/files-x.el index b71e9204f3..6b04518fe4 100644 --- a/lisp/files-x.el +++ b/lisp/files-x.el @@ -491,6 +491,13 @@ modify-dir-local-variable (cons `(,mode . ((,variable . ,value))) variables)))) + ;; Invalidate cache (may be needed if this .dir-locals.el file + ;; will be written with the same timestamp as is already present + ;; in the cache, see bug#13860). + (setq dir-locals-directory-cache + (assoc-delete-all (file-name-directory variables-file) + dir-locals-directory-cache)) + ;; Insert modified alist of directory-local variables. (insert ";;; Directory Local Variables\n") (insert ";;; For more information see (info \"(emacs) Directory Variables\")\n\n") Regards, /Johan On Wed, Aug 14 2019, Lars Ingebrigtsen wrote: > Johan Claesson writes: > >> Maybe i have misunderstood something but i find the cache >> mechanism for directory local variables unreliable in one rare >> case. If first .dir-locals.el is read and a binding say foo = 1 is >> inserted in the dir-locals-directory-cache. And then foo = 2 is >> written in the same second. Now next time the dir locals the old >> binding foo = 1 will be returned. The cache entry is considered >> valid when it should not. >> >> Of course it is unlikely that a user is typing so fast that they >> trigger this :). But it can be triggered from Lisp. I found out >> when playing with a ert test case that was tampering with a dir >> local. > > (I'm going through old bug reports that have unfortunately gotten no > responses yet.) > >> Here is a recipe for this: >> >> (defvar foo nil) >> (put 'foo 'safe-local-variable 'numberp) >> (let ((dir (make-temp-file "cache-test" t))) >> ;; Create .dir-locals.el with foo = 1. >> (with-temp-buffer >> (cd dir) >> (add-dir-local-variable nil 'foo 1) >> (save-buffer) >> (kill-buffer)) >> ;; Read it into dir-locals-directory-cache >> ;; and save .dir-locals.el with foo = 2. >> (with-temp-buffer >> (cd dir) >> (make-local-variable 'foo) >> (hack-dir-local-variables-non-file-buffer) >> (add-dir-local-variable nil 'foo 2) >> (save-buffer) >> (kill-buffer)) >> ;; Read it back again. >> ;; It should be 2 at this point but is 1 most of the times. >> ;; (At the rare occasion that seconds increase >> ;; between the two add-dir-local-variable it returns 1). >> (with-temp-buffer >> (cd dir) >> (make-local-variable 'foo) >> (hack-dir-local-variables-non-file-buffer) >> (delete-file dir-locals-file) >> (delete-directory dir) >> foo)) > > I'm unable to reproduce this problem in Emacs 27, but perhaps this could > be a problem if the file system doesn't have sub-second resolution? Are > there such file systems still in use (I mean, for something where'd you > store file with file-local variables)?