From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#13149: 24.3.50; Emacs thinks file was changed outside Emacs, but it was not Date: Fri, 18 Jan 2013 13:35:05 -0800 Message-ID: <50F9C009.9060708@cs.ucla.edu> References: <6CDE13E3BCAA4AFAAB8BCE105C6ABF12@us.oracle.com> <874njs19zb.fsf@yandex.ru> <50F3935A.2090003@yandex.ru> <50F41CE7.60306@gmail.com> <50F44E6B.8090007@cs.ucla.edu> <50F484CB.6010905@gmail.com> <50F4FB0B.5070003@cs.ucla.edu> <50F5192B.602@yandex.ru> <50F5928A.9010009@cs.ucla.edu> <50F5CC3D.5090802@yandex.ru> <50F5CE65.9030002@cs.ucla.edu> <50F5D3F5.6050604@yandex.ru> <50F5DA58.3020404@cs.ucla.edu> <50F5E1C1.2040301@yandex.ru> <50F5E9DB.1030309@gmail.com> <50F64149.6010704@cs.ucla.edu> <50F7D358.9030100@gmail.com> <50F86E12.3040707@cs.ucla.edu> <50F8D150.8030200@gmail.com> <50F8D731.5020001@cs.ucla.edu> <50F8D93B.1040901@yandex.ru> <50F8DCCB.1030602@cs.ucla.edu> <83a9s67wlr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1358544930 20047 80.91.229.3 (18 Jan 2013 21:35:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Jan 2013 21:35:30 +0000 (UTC) Cc: 13149@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 18 22:35:47 2013 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 1TwJb5-0003rj-Ou for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Jan 2013 22:35:35 +0100 Original-Received: from localhost ([::1]:33857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwJap-0004H4-1E for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Jan 2013 16:35:19 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwJal-0004Gn-V6 for bug-gnu-emacs@gnu.org; Fri, 18 Jan 2013 16:35:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TwJak-0001SV-Dq for bug-gnu-emacs@gnu.org; Fri, 18 Jan 2013 16:35:15 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwJak-0001SP-9l for bug-gnu-emacs@gnu.org; Fri, 18 Jan 2013 16:35:14 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TwJbW-0007Go-7c for bug-gnu-emacs@gnu.org; Fri, 18 Jan 2013 16:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Jan 2013 21:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13149 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: unreproducible moreinfo Original-Received: via spool by 13149-submit@debbugs.gnu.org id=B13149.135854496027938 (code B ref 13149); Fri, 18 Jan 2013 21:36:02 +0000 Original-Received: (at 13149) by debbugs.gnu.org; 18 Jan 2013 21:36:00 +0000 Original-Received: from localhost ([127.0.0.1]:39149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TwJbT-0007GZ-Dp for submit@debbugs.gnu.org; Fri, 18 Jan 2013 16:36:00 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:44893) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TwJbQ-0007GQ-Ny for 13149@debbugs.gnu.org; Fri, 18 Jan 2013 16:35:58 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id DA77139E810A; Fri, 18 Jan 2013 13:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cb0jh8ZD5Ru; Fri, 18 Jan 2013 13:35:06 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id EFEAD39E8008; Fri, 18 Jan 2013 13:35:05 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <83a9s67wlr.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.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:69998 Archived-At: On 01/17/13 23:56, Eli Zaretskii wrote: > Who said anything was actually written to the file? You'd need > 'fsync' to be sure, don't you? That depends on what one means by "actually written". :-) POSIX says a 'write' must result in st_mtime being updated some time before the file's time stamp is used (and 'fstat' and 'stat' both count as uses). It is not required that the written data or the updated st_mtime physically be stored on nonvolatile storage; if the system crashes, the updates might get lost.] Also, it's not required that st_mtime must be updated to the exact time stamp of the write -- it can be updated to a later time stamp, so long as the later time stamp comes before st_mtime's first use. But the point is that st_mtime must be updated "in memory", so to speak, just as the file's data must get updated "in memory", so that any uses of the file see the new st_mtime and the new data that got written. Here, we seem to have some cases where a write can occur but st_mtime is not updated before the next stat or fstat. I don't yet know how to characterize these cases, or how to work around them. Even Emacs's old approach (allow up to 1 second of slop) seems like it won't work in some cases that have been reported here: over 2 seconds of slop in , and over one minute of slop in ! One approach that I've been toying with is that Emacs could inspect the file system type, and if the file system is known to be reliable (ext2, ufs, zfs, ...) we stick with the new behavior in the trunk which uses fstat with no slop, but otherwise we fall back on the Emacs-24 behavior, using stat with 1 second of slop. This won't allow the instances of longer-than-1-second slops that we've seen reported here, but maybe that's good enough. I'm not particularly happy with this idea, but there is a limit to what Emacs can do to work around filesystem bugs.