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 20:41:34 +0200 Message-ID: <8338wij4td.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> <512C509B.7000205@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361904113 27234 80.91.229.3 (26 Feb 2013 18:41:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 18:41:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 19:42:14 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 1UAPTi-000149-Mf for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 19:42:14 +0100 Original-Received: from localhost ([::1]:47690 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAPTN-00031p-VQ for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 13:41:53 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAPTK-00031B-0E for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:41:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAPTI-0008DE-P2 for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:41:49 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:46286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAPTI-0008Cc-GY for emacs-devel@gnu.org; Tue, 26 Feb 2013 13:41:48 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MIU00600BV2N300@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 26 Feb 2013 20:41:38 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIU006L6BXD61C0@a-mtaout20.012.net.il>; Tue, 26 Feb 2013 20:41:38 +0200 (IST) In-reply-to: <512C509B.7000205@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:157396 Archived-At: > Date: Mon, 25 Feb 2013 22:05:15 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > On 02/25/2013 08:02 PM, Eli Zaretskii wrote:> > > > On Windows, as long as a file is open, no > > other application can write to it or remove the file. > > Is this true even if the file is network-mounted via NFS or CIFS? It is true if the other process runs on the same machine, I think. > > Is that the "atomic" nature you wanted? > > Partly, but it's not sufficient. I assume that one process can > read a file while another is writing to it That depends on how each process opens the file, exactly. It can be arranged that no other process can open the same file, although I think the default open flags don't do that. > which means that the readlink and symlink replacements may not be > atomic. Don't know about this part, I will have to run some tests. Since changes in file metadata _are_ atomic on NTFS (see below) the answer to that appears to depend on whether NTFS symlinks are implemented as metadata or as data. I don't know which is the case, for now. > I mean that there's an abstract machine where a symbolic link is > either present or absent, and where readlink ("a", ...), > symlink ("b", "a"), and unlink ("a") either succeed or fail and affect > the abstract machine in an all-or-nothing way. For example, if > the symbolic link doesn't exist and one process runs > symlink ("very long link contents", "a") > at the same time another process runs readlink ("a", buf, sizeof buf) > where buf is large enough, then the readlink should either fail > (no symlink present yet) or should succeed with > the buffer containing all the link contents; it shouldn't succeed with > partial contents such as "very long link co". It's hard to give a definitive answer to that, as documentation is scarce and most of it unofficial. My conclusion from reading a lot of technical stuff is that changes to file metadata are atomic on NTFS, and single-sector read/write operations are also atomic. That means 'unlink' (file deletion) is atomic, as it affects metadata only, and so is 'rename' and 'chmod'. Reads and writes are probably atomic as long as they are short. I found nothing about the APIs used by 'symlink' and 'readlink', so all I can say that I hope they are atomic, because the amount of data they read/write is small. I will try to test this when I have time. In any case, all this atomicity stuff is important for locking files on Windows volumes, it won't help us with the more important problems related to Posix and Windows hosts editing the same file on a networked filesystem. We could (and should) probably make the Windows implementation of locking more robust in the face of potential races between several instances of Emacs running on Windows, but that is secondary to avoiding problems for Emacs running on Posix hosts.