From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Locking files for CLASH_DETECTION now supported on MS-Windows Date: Tue, 26 Feb 2013 19:45:45 +0200 Message-ID: <837glvhsty.fsf@gnu.org> References: <83wqtwi90o.fsf@gnu.org> <512BA7F6.4010304@cs.ucla.edu> <83txp0i6cy.fsf@gnu.org> <512BB3C1.40201@cs.ucla.edu> <512C17E1.7040307@cs.ucla.edu> <83d2vniuxv.fsf@gnu.org> <512C39F3.8050105@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361902055 5528 80.91.229.3 (26 Feb 2013 18:07:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 18:07:35 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 19:07:58 2013 Return-path: Envelope-to: ged-emacs-devel@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 1UAOwT-0001e5-KR for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 19:07:53 +0100 Original-Received: from localhost ([::1]:60119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAOw8-0006on-Ib for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 13:07:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAOw2-0006aZ-U3 for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:07:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAOb9-00029i-6A for emacs-devel@gnu.org; Tue, 26 Feb 2013 12:46:28 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:64588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAOb8-000296-SH for emacs-devel@gnu.org; Tue, 26 Feb 2013 12:45:51 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MIU0090099XER00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 26 Feb 2013 19:45:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIU009QJ9CCDS20@a-mtaout21.012.net.il>; Tue, 26 Feb 2013 19:45:49 +0200 (IST) In-reply-to: <512C39F3.8050105@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157394 Archived-At: > Date: Mon, 25 Feb 2013 20:28:35 -0800 > From: Daniel Colascione > CC: Paul Eggert , emacs-devel@gnu.org > > If we really need atomicity under Windows, Transactional NTFS will work for more > users than symbolic links will. No, I don't think we want Transactional NTFS (or TxF for short), for several good reasons. First, Microsoft itself is considering deprecating TxF, and strongly recommends that developers use alternatives. A quotation from http://msdn.microsoft.com/en-us/library/windows/desktop/hh802690%28v=vs.85%29.aspx, which speaks for itself: Abstract Microsoft strongly recommends developers investigate utilizing the discussed alternatives (or in some cases, investigate other alternatives) rather than adopting an API platform which may not be available in future versions of Windows. Introduction TxF was introduced with Windows Vista as a means to introduce atomic file transactions to Windows. It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, and in transactions spanning multiple sources - such as the Registry (through TxR), and databases (such as SQL). While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers. Second, TxF is not really meant for atomicity in the sense that we are looking for in this thread. It is meant to preserve consistency in a scenario of a catastrophic failure, such as an application or system crash. E.g., this page: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365738%28v=vs.85%29.aspx clearly says near its end that several writers to the same file -- exactly what bothers us here -- is not a supported scenario by TxF. Read this page: http://msdn.microsoft.com/en-us/library/windows/desktop/aa964931%28v=vs.85%29.aspx to see how TxF is designed for scenarios that are very different from what we are considering here. E.g.: Reparse Points Changes to reparse points are transacted, which means that if a new reparse point gets assigned to a file in a transaction, it is not visible to the other transactions. Similarly, changes or removal of an existing reparse point are not visible until commit. (NTFS symlinks are a kind of reparse point.) This is exactly the opposite of what we would like to happen.