From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Locking files for CLASH_DETECTION now supported on MS-Windows Date: Mon, 25 Feb 2013 22:05:15 -0800 Organization: UCLA Computer Science Department Message-ID: <512C509B.7000205@cs.ucla.edu> 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> 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 1361858726 3511 80.91.229.3 (26 Feb 2013 06:05:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2013 06:05:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 07:05:49 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 1UADfh-0001xp-23 for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 07:05:49 +0100 Original-Received: from localhost ([::1]:34368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UADfM-0004jT-2y for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2013 01:05:28 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UADfI-0004j1-Vy for emacs-devel@gnu.org; Tue, 26 Feb 2013 01:05:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UADfH-00042l-Vs for emacs-devel@gnu.org; Tue, 26 Feb 2013 01:05:24 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:36970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UADfA-0003z7-Lb; Tue, 26 Feb 2013 01:05:16 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E6A28A60001; Mon, 25 Feb 2013 22:05:15 -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 3SdWQS317XMQ; Mon, 25 Feb 2013 22:05:15 -0800 (PST) Original-Received: from [192.168.1.9] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 75C7639E8100; Mon, 25 Feb 2013 22:05:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 In-Reply-To: <83d2vniuxv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:157377 Archived-At: 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? I'd be surprised if it were true for NFS, as that's not the standard NFS semantics. > 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, which means that the readlink and symlink replacements may not be atomic. >> Are readlink, symlink, and unlink atomic on MS-Windows? > > Please define "atomic" for these cases, and I will think about that. 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".