From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13149: 24.3.50; Emacs thinks file was changed outside Emacs, but it was not Date: Sat, 02 Feb 2013 11:38:57 +0200 Message-ID: <83k3qrawcu.fsf@gnu.org> References: <6CDE13E3BCAA4AFAAB8BCE105C6ABF12@us.oracle.com> <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> <50F9C009.9060708@cs.ucla.edu> <50F9D213.3070901@yandex.ru> <50F9EF01.5000703@cs.ucla.edu> <50F9F250.1030406@yandex.ru> <50FA06F1.2000308@cs.ucla.edu> <50FA1AEF.9070700@yandex.ru> <50FA265E.80301@cs.ucla.edu> <510C2E22.9010807@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1359799952 19183 80.91.229.3 (2 Feb 2013 10:12:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Feb 2013 10:12:32 +0000 (UTC) Cc: 13149@debbugs.gnu.org, dgutov@yandex.ru To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 02 11:12:52 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 1U1a5Y-0002j8-J0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Feb 2013 11:12:48 +0100 Original-Received: from localhost ([::1]:44257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1a5G-00048M-6z for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Feb 2013 05:12:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1a5D-00048H-OA for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 05:12:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U1a5C-0004Bu-3T for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 05:12:27 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1ZZ1-0005Oq-9m for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 04:39:11 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U1ZZr-0005DI-3i for bug-gnu-emacs@gnu.org; Sat, 02 Feb 2013 04:40:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Feb 2013 09:40: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.135979799520019 (code B ref 13149); Sat, 02 Feb 2013 09:40:02 +0000 Original-Received: (at 13149) by debbugs.gnu.org; 2 Feb 2013 09:39:55 +0000 Original-Received: from localhost ([127.0.0.1]:60438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1ZZj-0005Cp-29 for submit@debbugs.gnu.org; Sat, 02 Feb 2013 04:39:55 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:65446) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1ZZe-0005CY-Lo for 13149@debbugs.gnu.org; Sat, 02 Feb 2013 04:39:52 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MHL00C006RXFA00@a-mtaout21.012.net.il> for 13149@debbugs.gnu.org; Sat, 02 Feb 2013 11:38:56 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHL00C6A6SV6DB0@a-mtaout21.012.net.il>; Sat, 02 Feb 2013 11:38:56 +0200 (IST) In-reply-to: <510C2E22.9010807@cs.ucla.edu> X-012-Sender: halo1@inter.net.il 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:70598 Archived-At: > Date: Fri, 01 Feb 2013 13:05:38 -0800 > From: Paul Eggert > Cc: 13149@debbugs.gnu.org, 'Dmitry Gutov' > > I stared at the code a bit and found an unlikely bug > that would cause the reported symptoms. The bug occurs if the > first write-region to a buggy file system happens to be > an append that appends nothing. If this occurs, Emacs > incorrectly concludes that the file system is not buggy, > and later uses of write-region to that file system (assuming > no other non-buggy file systems are used in the meantime) > will behave in the bad way that Drew reported. > > I installed a fix for this bug as trunk bzr 111656. > I'd be surprised if this fixes Drew's bug though. Me too, but who knows? > Eli, does MS-Windows conform to POSIX by updating st_mtime when > Emacs creates a file (open with O_CREAT on a file that didn't > previous exist) or truncates a file (open with O_TRUNC > on a file that previously existed)? MS-Windows doesn't conform to Posix, period ;-) It's hard to say something definitive here, especially since some of this depends on the filesystem being used (Drew uses FAT32, most others use NTFS). I cannot find any documentation on this issue. The only thing that Windows promises in its docs is that st_mtime is updated when the last file descriptor for the file is closed. So the time stamp might not be up to date by the time we look at it in write-region, because we use 'fstat' there before closing the descriptor we used for writing. However, the code that determines valid_timestamp_file_system right after that should catch any problems caused by this, and update the buffer's modtime to the value actually recorded in the filesystem. Perhaps FAT32 (see below) should always do this, i.e. we should disable the optimization of probing its time stamp validity only once? > For example, if Emacs uses O_TRUNC on a file that is already empty, > does MS-Windows update the file's time stamp even though the file > has not changed? My testing indicates that a file on NTFS has its time stamp changed in this scenario, while a file on FAT32 will not. (I used a USB flash device for this testing, as I have no other volume accessible to me that is formatted as FAT32.) However, when the file is closed, the time stamp does get updated on FAT32 as well. So the code which determines valid_timestamp_file_system should have caught this as well. And anyway, Drew's use case involves a non-empty file, so this precise scenario is not a problem there. For a non-empty file, when it is truncated by opening it with O_TRUNC, the file's size reflects truncation on both NTFS and FAT32, at least on my XP system.